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

Abstract

The object is to provide an information processing program that improves operability. [Solution] The information processing program displays the game screen being played, is capable of receiving multiple invitation information from an external device inviting the player to participate in one of multiple types of invitation games, and displays an announcement image that corresponds to the received invitation information and that allows identification of part of the game information related to the invitation game, while maintaining the display of the game screen being played.When multiple invitation information is received, an announcement image is displayed for each invitation information, and when a player inputs an operation to select an announcement image, a predetermined image that includes at least more detailed game information than the announcement image and an operation unit that accepts an operation to participate in the invitation game is displayed in an identifiable state on the game screen being played, and when a participation operation is input to the operation unit, causes the computer to execute processing to participate in the invitation game.

Description

[Technical Field]

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

[0002] Conventionally, communication games in which multiple players can participate (hereinafter referred to as multiplayer) have been known. In multiplayer games, it is necessary to match people who wish to participate in the game. For example, Patent Document 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.

[0003] According to this game system, a mark indicating that the invitation information has been received 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 game to which the player has been invited is displayed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6634534 Summary of the Invention [Problem to be solved by the invention]

[0005] In the above game system, the operation of the player who receives the invitation information may become complicated. Therefore, further improvement in operability is desired.

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

[0007] In order to solve the above problem, an information processing program a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; The notification image Or the specific image a process of pausing the predetermined game being played when a player's operation to select The notification image Or the specific image a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; The computer executes the following: The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; Even after a predetermined time has elapsed since the start of display of the specific image and the specific image is no longer displayed, the notification image can be displayed in the notification mode.

[0008] Also, The notification image is displayed once regardless of the number of invitations received. That's fine.

[0009] Also, and when a predetermined operation is input while the predetermined game is suspended, the computer is caused to execute a process of resuming the predetermined game, and the notification image is displayed in the notification manner even after the predetermined game is resumed. That's fine.

[0010] Also, The notification image is displayed in the same position on the screen of a game other than the predetermined game as when the predetermined game is being played. That's fine.

[0011] In order to solve the above problem, an information processing method includes: An information processing method performed by a computer, comprising: The computer a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; The notification image Or the specific image a process of pausing the predetermined game being played when a player's operation to select The notification image Or the specific image a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; and The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; Even after a predetermined time has elapsed since the start of display of the specific image and the specific image is no longer displayed, the notification image can be displayed in the notification mode.

[0012] In order to solve the above problem, the information processing system includes: An information processing system in which a player terminal and an external device are communicatively connected, The player terminal a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; The notification image Or the specific image a process of pausing the predetermined game being played when a player's operation to select The notification image Or the specific image a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; and The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; Even after a predetermined time has elapsed since the start of display of the specific image and the specific image is no longer displayed, the notification image can be displayed in the notification mode. [Effects of the Invention]

[0013] According to the present invention, it is possible to improve operability. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. [Figure 2] Fig. 2A is a diagram illustrating the hardware configuration of a player terminal, and Fig. 2B is a diagram illustrating the hardware configuration of a server. [Figure 3] Fig. 3A is a diagram showing an example of a party formation screen. Fig. 3B is a diagram explaining 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 explaining an example of a play content selection page on the quest screen. [Figure 4] 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, and Fig. 4C is a diagram illustrating an example of a result screen. [Figure 5] 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 a room selection page. Fig. 5C is a diagram illustrating an example of a target player selection page. Fig. 5D is a diagram illustrating an example of a room details page. [Figure 6] Fig. 6A is a diagram illustrating an example of a notification of receipt of invitation information on a normal screen. Fig. 6B is a diagram illustrating an example of a notification of receipt of invitation information on a 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. [Figure 7]Fig. 7A is a diagram illustrating priority points, and Fig. 7B is a diagram illustrating update conditions for priority points. [Figure 8] FIG. 8 is a first diagram illustrating the list update process. [Figure 9] FIG. 9 is a second diagram illustrating the list update process. [Figure 10] FIG. 10 is a third diagram illustrating the list update process. [Figure 11] FIG. 11 is a fourth diagram illustrating the list update process. [Figure 12] Fig. 12A is a diagram illustrating the play status of the player terminal, and Fig. 12B is a diagram illustrating the timing for confirming receipt of invitation information. [Figure 13] FIG. 13 is a sequence diagram illustrating basic processing of the player terminal and the server. [Figure 14] FIG. 14 is a sequence diagram illustrating the processing of the player terminals and the server when multiplay is executed. [Figure 15] FIG. 15 is a sequence diagram illustrating the processing of the player terminal and the server when participation in multiplay is not possible. [Figure 16] FIG. 16 is a sequence diagram illustrating the processing of the player terminal and the server when participation in multiplay is refused. [Figure 17] FIG. 17 is a diagram illustrating the memory configuration and computer functions of the player terminal. [Figure 18] FIG. 18 is a flowchart illustrating an example of terminal-side game processing in a player terminal. [Figure 19] FIG. 19 is a flowchart illustrating an example of room creation-related processing in a player terminal. [Figure 20] FIG. 20 is a flowchart illustrating an example of the invitation information reception process in the player terminal. [Figure 21] FIG. 21 is a flowchart illustrating an example of the invitation information confirmation process in the player terminal. [Figure 22]FIG. 22 is a first flowchart illustrating an example of post-reception processing of invitation information in a player terminal. [Figure 23] FIG. 23 is a second flowchart illustrating an example of post-reception processing of invitation information in a player terminal. [Figure 24] FIG. 24 is a flowchart illustrating an example of a multiplay ending process in a player terminal. [Figure 25] FIG. 25 is a diagram illustrating the memory configuration and computer functions of the server. [Figure 26] FIG. 26 is a flowchart illustrating an example of server-side game processing in the server. [Figure 27] FIG. 27 is a flowchart illustrating an example of a request information receiving process in the server. [Figure 28] FIG. 28 is a flowchart illustrating an example of information update processing in the server. [Figure 29] FIG. 29 is a flowchart illustrating an example of a multiplay end process in the server. [Figure 30] FIG. 30 is a flowchart illustrating an example of the sorting process in the server. DETAILED DESCRIPTION OF THE INVENTION

[0015] An embodiment of the present invention will be described in detail below with reference to the accompanying drawings. Dimensions, materials, and other specific values ​​shown in the embodiment are merely examples for ease of understanding and do not limit the present invention unless otherwise specified. In this specification and drawings, elements having substantially the same functions and configurations are designated by the same reference numerals to avoid redundant explanation, and elements not directly related to the present invention are not shown.

[0016] (Overall configuration of information processing system S) 1 is an explanatory diagram showing a schematic configuration of an information processing system S. The information processing system S is a so-called client-server system that includes a player terminal 1, a server 100, and a communication network 200 having a communication base station 200a.

[0017] The player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 broadly includes electronic devices that can establish a wireless or wired communication connection with the server 100. Examples of the player terminal 1 include smartphones, mobile phones, tablet devices, personal computers, game consoles, etc. In this embodiment, a case will be described in which a smartphone is used as the player terminal 1.

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

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

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

[0021] (Hardware Configuration of Player Terminal 1 and Server 100) Fig. 2A is a diagram illustrating the hardware configuration of the player terminal 1. Fig. 2B is a diagram illustrating the hardware configuration of the server 100. 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 unit 18, a communication unit 20, an input unit 22, and an output unit 24.

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

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

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

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

[0026] The storage unit 18 is configured with a 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 into the memory 12 (RAM) by the CPU 10.

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

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

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

[0030] (Game Contents) Next, the content of the game provided by the information processing system S (game device G) of this embodiment will be described using an example. In this embodiment, a so-called battle game is provided in which ally characters battle against enemy characters. Specifically, in the game of this embodiment, multiple ally characters are provided. A player selects multiple ally characters (here, three) from the provided ally characters to form a party. In addition, the player can play multiple types of battle games with different enemy characters and difficulty levels. In other words, in the embodiment, multiple types of battle games are provided. In a battle game, the player controls the ally characters formed into a party, and the objective is to defeat enemy characters and earn rewards.

[0031] FIG. 3A is a diagram showing an example of a party formation screen. FIG. 3B is a diagram explaining 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 explaining an example of a play content selection page on the quest screen. Game screens such as those shown in FIGS. 3A, 3B, 3C, and 3D are displayed on the display 26 of the player terminal 1. In this embodiment, the game screens are broadly divided into normal screens and battle screens.

[0032] The normal screen is a screen that is mainly used by the player to confirm various settings and information. On the other hand, the battle screen is a screen that is 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 screens are broadly 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 quest screens shown in FIGS. 3C and 3D.

[0033] The party formation screen and quest screen are made up of multiple pages, and the pages are switched by the player's operation. On the normal screen, a header display area 30 is provided at the top of the display 26. The header display area 30 displays a stamina display bar 32 that indicates the player's stamina.

[0034] Stamina is a parameter required to play a battle game. In this embodiment, multiple types of battle games are provided, and each battle game has a set stamina consumption value required to play. Since a player consumes stamina to play a battle game, if the player does not have enough stamina, the player cannot play the battle game.

[0035] Although a detailed explanation will be omitted, when a player wins a battle game, the player can acquire a predetermined value as player experience points. Then, each time the player experience points reach a certain value, the player level increases. A stamina upper limit is set for the player level, and as the player level increases, the stamina upper limit also increases. Stamina recovers by a predetermined value (e.g., 1 point) every fixed time (e.g., 5 minutes) within the upper limit. The stamina display bar 32 is displayed so that the current remaining amount of stamina can be visually grasped relative to the stamina upper limit.

[0036] Additionally, a notification image 34 is displayed on the left edge of the header display area 30. As will be described in more detail below, the notification image 34 notifies the player that invitation information for a battle game or guide information for an event has been received. When neither invitation information nor guide information has been received, the notification image 34 is displayed in a non-notification mode. Note that the notification image 34 in the non-notification mode is displayed in a lighter color overall. In contrast, when at least either invitation information or guide information has been received, the notification image 34 is displayed in a notification mode. The notification image 34 in the notification mode is highlighted in a more noticeable color than the non-notification mode.

[0037] Furthermore, 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 sections that can be operated (tapped) by the player. Here, as examples of operation sections, the menu bar 36 is provided with a home screen selection section 36a marked "Home" and a party organization screen selection section 36b marked "Party" and a quest screen selection section 36c marked "Quest" and an information confirmation screen selection section 36d marked "Info."

[0038] When the home screen selection portion 36a is tapped, the home screen is displayed on the display 26. When the party formation screen selection portion 36b is tapped, the party formation screen shown in Fig. 3A is displayed on the display 26. 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 page) shown in Fig. 3C is displayed on the display 26.

[0039] As described above, the normal screen is broadly divided into four screens. In the menu bar 36, the operation section corresponding to each screen is highlighted so that the screen currently displayed on the display 26 can be identified. When a page transition occurs within the normal screen, or when a transition occurs to a different normal screen, the stamina display bar 32, notification image 34, and menu bar 36 remain displayed. In other words, when a screen transition occurs within the normal screen, images other than the header display area 30 and menu bar 36 are switched.

[0040] The party formation screen shown in FIG. 3A displays all ally characters possessed by the player. The player can select three ally characters from the displayed ally characters to form a party. Here, up to six parties can be formed and stored. Each ally character is associated with an experience value and a level. The experience value increases when a player wins a battle game (described later) or when a predetermined item is used. The level is set in accordance with the experience value, and increases each time the experience value reaches a predetermined value. Note that a maximum level is set for each ally character, and the level can only increase within the range of the maximum level.

[0041] Furthermore, base values ​​for combat power, such as life points, attack power, and defense power, are set for each ally character according to their level. The higher the combat power of an ally character, the more advantageously the player can progress through the battle game. Furthermore, the base values ​​set for each ally character increase as the level increases.

[0042] Furthermore, on the party organization screen, the player can equip (set) weapons and armor for the ally characters included in the party. Each piece of equipment has an added value for attack power, defense power, etc. When equipment is equipped, the added value of each piece of equipment is added to the above base value, thereby increasing the combat power of the ally character.

[0043] The information confirmation screen shown in FIG. 3B displays player information about the player. Examples of player information displayed include the player's name, player experience points, player level, player rank, number of characters owned (number of ally characters owned by the player), number of followers, and number of mutual followers. In this embodiment, a follower refers to another player who is set by a player as a favorite or comrade. In this embodiment, a mutual follower refers to players who are set as mutual followers of each other.

[0044] The battle game selection page of the quest screen shown in FIG. 3C displays the types of battle games available, i.e., multiple selection tabs 38 listing the names of the battle games. Here, ten types of battle games are available, and ten selection tabs 38 are displayed. Each battle game has its own unlocking conditions. Examples of unlocking conditions include the player's experience points, player level, and player rank being equal to or greater than a predetermined value, or the player having completed another predetermined battle game.

[0045] A player can only play battle games for which the unlocking conditions are met. Therefore, on the battle game selection page, the selection tabs 38 for battle games for which the unlocking conditions are not met are displayed with a lock, as shown in the figure. Furthermore, only the selection tabs 38 for battle games for which the unlocking conditions are met will accept player operations (tap).

[0046] When the selection tab 38 is tapped on the battle game selection page, the play content selection page shown in FIG. 3D is displayed. On this play content selection page, a party to be used in the battle game can be selected from the parties organized on the party organization screen. In this embodiment, the play types include single play, in which the player plays the battle game alone, and multiplay, in which the player plays the battle game cooperatively with other players via communication. The play content selection page displays a single play tab 40a and a multiplay tab 40b.

[0047] 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, when the single play tab 40a is operated after the type of battle game and the party to be used in the battle game have been selected, single play begins. Note that, hereinafter, the ally characters included in the party used in the battle game, i.e., the ally characters operated by the player in the battle game, are referred to as "player characters." In the battle game, the player operates the input unit 22 of the player terminal 1 to move the player character.

[0048] During the battle game, a battle screen is displayed as shown in FIG. 4B. On the battle screen, a player character and an enemy character are displayed on the display 26. The player character moves in accordance with the player's operation, inflicting damage on the enemy character and receiving damage from the enemy character. The enemy character also moves under computer control, inflicting damage on the player character and receiving damage from the player character.

[0049] When damage points are awarded to an enemy character, the damage points are subtracted from the enemy character's life points. Similarly, when damage points are awarded to a player character, the damage points are subtracted from the player character's life points. When the enemy character's life points reach 0, the player wins, and when all player characters' life points reach 0, the player loses.

[0050] Here, as shown in FIG. 4B, the menu bar 36 that is displayed on the normal screen is hidden on the battle screen. 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, on the battle screen, operation tabs 42 are displayed in the header display area 30. The display position of the operation tabs 42 is the same as the position in the header display area 30 where at least a portion of the notification image 34 is displayed on the normal screen.

[0051] When the operation tab 42 is tapped during a battle game, the battle game is interrupted. At this time, a pause screen (not shown) is displayed on the display 26. The pause screen is provided with a retire operation section and a resume operation section, and the player can select to retire (end) or resume the battle game by tapping these operation sections.

[0052] When the battle game ends normally (normal end), a result screen is displayed on the display 26, as shown in Fig. 4C. In this embodiment, normal end of the battle game includes three end patterns: an early end due to retirement, a win end in which victory in the battle game is confirmed, and a loss end in which defeat in the battle game is confirmed. Fig. 4C shows a result screen at the end of a win as an example, but the result screen differs for each end pattern.

[0053] An end operation section 44 labeled "Close" is displayed on the result screen, and when this end operation section 44 is tapped, the display on the display 26 switches from the battle screen to the normal screen. In other words, the result screen is a part of the battle screen. The normal screen that switches from the result screen may be the screen that was displayed immediately before switching to the battle screen, or may be a predetermined screen such as the home screen. In this way, the battle game ends when the display of the result screen ends.

[0054] 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 a room selection page. FIG. 5C is a diagram illustrating an example of a target player selection page. FIG. 5D is a diagram illustrating an example of a room details page. As shown in FIG. 5A, assume that the multiplay tab 40b is tapped with the type of battle game and the party to be used in the battle game selected.

[0055] In this case, the room selection page of the quest screen is displayed as shown in Figure 5B. On the room selection page, a room creation tab 46 labeled "Create a Room" is displayed. In this embodiment, the term "room" refers to a place where all players participating in multiplayer play can share information, and may also refer to an area reserved on the server 100 for multiplayer play.

[0056] When playing multiplayer, a player can create their own room by tapping the room creation tab 46 (inputting a request operation). In the following, a player who creates a room in multiplayer will be called a host player. A player who joins a room created by another player will be called a guest player.

[0057] When the room creation tab 46 is tapped, a target player selection page of the quest screen is displayed, as shown in FIG. 5C. On the target player selection page, a follower tab 48a labeled "Follower," a mutual follower tab 48b labeled "Mutual Follower," and a random tab 48c labeled "Random" are displayed. On the target player selection page, a player creating a room can select targets (guest players) to invite to the room they created.

[0058] Specifically, when the follower tab 48a is operated, a player who has been set as a follower by the player who creates the room is set as a target person who can receive the invitation information. In this embodiment, only players who have been set as targets can receive the invitation information, and players who are not set as targets will not receive the invitation information. Furthermore, as will be described in detail later, a target person will not receive the invitation information unless certain conditions are met. Therefore, a target person can be said to be a player who has obtained the right to receive the invitation information.

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

[0060] For example, when the random tab 48c is tapped as shown in FIG. 5C, the room details page of the quest screen is displayed as shown in FIG. 5D. The room details page displays various information (room information) including party information indicating the party selected by the host player. The host player's room details page also displays a start tab 50 marked "Ready." When the host player taps the start tab 50, multiplayer play begins.

[0061] FIG. 6A is a diagram illustrating an example of a notification of the receipt of invitation information on a normal screen. FIG. 6B is a diagram illustrating an example of a notification of the receipt of invitation information on a battle screen. FIG. 6C is a diagram illustrating an example of an invitation information image 54. FIG. 6D is a diagram illustrating an example of a pause screen. For example, as shown in FIG. 6A, assume that an information confirmation screen is displayed on the display 26 of the player terminal 1 of the target player. In this state, when the player terminal 1 receives invitation information, the notification image 34 in the header display area 30 switches from a non-notification mode to a notification mode as shown in the figure. Note that, as will be described in detail 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 player terminal 1 of the number of pieces of invitation information held by the player terminal 1.

[0062] The display 26 also has a thumbnail display area 52. The thumbnail display area 52 is provided at the upper left edge of the display 26, near the notification image 34. More specifically, the thumbnail display area 52 is provided below the notification image 34. Normally, nothing is displayed in the thumbnail display area 52, and the player cannot identify it.

[0063] Then, when the player terminal 1 receives new invitation information, a thumbnail image 52a is displayed in the thumbnail display area 52. The thumbnail images 52a are provided for each type of battle game, and for example, the thumbnail image 52a corresponding to the battle game selected by the host player, i.e., the type of battle game to which the host player has been invited, is displayed in the thumbnail display area 52.

[0064] That is, when new invitation information is received, a thumbnail image 52a corresponding to the received invitation information is displayed in the thumbnail display area 52. Here, an enemy character of the battle game is displayed in the thumbnail image 52a. The player can understand the type of the battle game to which he has been invited by the enemy character displayed in the thumbnail image 52a.

[0065] The content displayed in 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 entire 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 has been invited by using the thumbnail image 52a.

[0066] However, the thumbnail image 52a is not limited to a form that allows identification of the type of battle game. For example, the thumbnail image 52a may be configured to allow identification of whether the invited person is a follower, a mutual follower, or a random person. Alternatively, the thumbnail image 52a may be configured to allow identification of some information related to the host player, such as the name or level of the host player. In any case, the thumbnail image 52a may be configured to display something that corresponds to the invitation information, and the display form and information that can be identified by the player are not particularly limited.

[0067] The thumbnail display area 52 is provided within a display area in which various game images are displayed on the normal screen and the battle screen. The thumbnail image 52a is displayed while maintaining the display of the game screen being played. In other words, the thumbnail image 52a is displayed superimposed on the game screen being played. However, a transparency is set for the thumbnail image 52a, so that the player can see the game screen being played through the thumbnail image 52a even when the thumbnail image 52a is displayed.

[0068] Furthermore, the thumbnail image 52a is automatically erased from the thumbnail display area 52 and becomes invisible after a predetermined time (for example, 10 seconds) has elapsed. In other words, the thumbnail image 52a is displayed only for a predetermined time after new invitation information is received. However, even after the thumbnail image 52a becomes invisible, the notification image 34 continues to be displayed in an informing manner. Therefore, the player can know that invitation information has been received even after the thumbnail image 52a becomes invisible.

[0069] 6B, for example, assume that a battle screen is displayed on the display 26 of the target player terminal 1. As described above, on the battle screen, the operation tab 42 is normally displayed in the header display area 30 (see FIG. 4B), but when the player terminal 1 receives invitation information, the operation tab 42 is switched to a notification image 34 in a notification mode, as shown in the figure.

[0070] Furthermore, even when the battle screen is being displayed, if new invitation information is received, just as when the normal screen is being displayed, a thumbnail image 52a is displayed in the thumbnail display area 52. Note that, although the position of the thumbnail display area 52 is assumed to be the same for the normal screen and the battle screen, the position of the thumbnail display area 52 may be different for the normal screen and the battle screen.

[0071] Furthermore, the thumbnail image 52a is common to both the normal screen and the battle screen. However, different thumbnail images 52a may be 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 currently displayed screen. As one example, the thumbnail image 52a displayed on the normal screen may include 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, making it easier for the player to notice.

[0072] While the battle screen is displayed, i.e., during a battle game, the player is frequently required to perform operations. Furthermore, depending on the content of the battle game, the timing of the player's operations may be important. On the other hand, while the normal screen is displayed, the timing of the player's operations is not important. Therefore, while the battle screen is displayed, it is often difficult for the player to respond immediately or to grasp detailed information when the thumbnail image 52a is displayed, compared to when the normal screen is displayed. Therefore, as described above, if the thumbnail images 52a displayed on the battle screen are simpler than the thumbnail images 52a displayed on the normal screen, the risk of the player feeling annoyed is reduced.

[0073] It should be noted that when the thumbnail image 52a that was once hidden is redisplayed, the thumbnail image 52a may continue to be displayed until the invitation information is deleted.

[0074] In this embodiment, the player terminal 1 may receive multiple 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, suppose that the player terminal 1 is holding two pieces of invitation information and has newly received a third piece of invitation information.

[0075] 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. In this way, when multiple invitation information pieces are received, a thumbnail image 52a is displayed for each invitation information piece. This allows the player to easily understand the number of invitation information pieces received and the type of battle game to which they are invited.

[0076] Here, when new invitation information is received, the thumbnail image 52a corresponding to the 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.

[0077] FIG. 6C shows a state in which the notification image 34 or thumbnail image 52a is tapped while the battle screen shown in FIG. 6B is displayed. That is, when the notification image 34 or 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 thumbnail image 52a is tapped while the battle screen is displayed, the battle game is paused, just as when the operation tab 42 is tapped. At this time, the paused battle screen is frozen and the entire display 26 goes dark. Furthermore, when the battle screen is frozen and displayed, the notification image 34 is replaced by the operation tab 42, and an invitation information image 54 is displayed superimposed on the paused battle screen.

[0078] An invitation information image 54 is displayed for each thumbnail image 52a, that is, for each piece of invitation information. Therefore, in this example, three pieces of invitation information have been received, so three invitation information images 54 are displayed. The invitation information image 54 includes a game information display section 54a and an operation section 54b. The game information display section 54a displays some or all of the information included in the invitation information. Specifically, the type of battle game is displayed in the game information display section 54a by an image of an enemy character appearing in the battle game (the character image on the left in the figure).

[0079] Note that here, the image of the enemy character displayed in the game information display section 54a, i.e., the image indicating the type of battle game, is the same as the image displayed in the thumbnail image 52a. Also, the game information display section 54a displays information indicating the difficulty level of the battle game (shown as "Advanced" or "Intermediate" in the figure). 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 levels of difficulty. Therefore, the game information display section 54a displays the difficulty level of the battle game along with the type of battle game.

[0080] Furthermore, the game information display portion 54a displays images of the ally characters participating in the battle game (the character images on the right side in the figure). Here, of the ally characters participating in the battle game, the ally characters selected by the host player are displayed. In this way, the game information display portion 54a of the invitation information image 54 displays game information about the battle game corresponding to the thumbnail image 52a.

[0081] The game information display section 54a displays more detailed information than the information displayed by the thumbnail image 52a. Specifically, the thumbnail image 52a allows the player to ascertain only the type of battle game. On the other hand, the game information display section 54a allows the player to ascertain the type of battle game, the difficulty level of the battle game, the types of some of the ally characters participating in the battle game, information about the host player, and the like.

[0082] The operation unit 54b is provided with a delete tab marked "Delete" and a join tab marked "Join." The delete tab accepts a delete operation for deleting invitation information, and the join tab accepts a join operation for joining a battle game to which the player has been invited. The operation unit 54b displays the corresponding game information display unit 54a in an 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.

[0083] For example, as shown in Fig. 6C, of ​​the three operation sections 54b in the upper, middle, and lower rows, suppose the delete tab in the upper operation section 54b is tapped. In this case, the invitation information corresponding to the invitation information image 54 in the upper row is deleted, and the invitation information image 54 in the upper row is hidden. However, in this case, the invitation information images 54 in the middle and lower rows remain displayed.

[0084] Furthermore, when the participation tab is tapped and a participation operation is input, processing is executed to participate in the invited battle game. Specifically, when the participation operation is input, participation information is transmitted from the target player's player terminal 1 to the server 100. When the participation information is input, the server 100 determines whether or not the target player is allowed to enter the invited room.

[0085] For example, if a multiplayer game has already started in the invited room (play in progress), if the upper limit number of guest players has entered the room (full), or if the room has disappeared (disbanded), it is determined that entry into the room is not possible. In this case, an entry-prohibited screen (not shown) is displayed on the display 26 of the player terminal 1 to inform the player that entry into the room is not possible.

[0086] In response to this, it is assumed that the server 100 determines that entry into the room is possible. In this case, the player information of the target player who transmitted the participation information is added to the room, and the room information is updated. In this way, when the participation operation is performed and entry into the room is possible, the target player 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.

[0087] At this time, a room details page (not shown) is displayed on the player terminal 1 of the guest player (hereinafter referred to as the "guest terminal"). Based on 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 room details page displayed on the player terminal 1 of the host player (hereinafter referred to as the "host terminal") has a start tab 50. On the other hand, the room details page displayed on the guest terminal does not have a start tab 50. Therefore, only the host player can start multiplay.

[0088] Note that the room details page displayed on the guest terminal does not have an operation unit for accepting an operation to leave a room. In other words, a guest player cannot officially leave a room that he or she has entered. This prevents guest players from repeatedly entering and leaving the room, and allows for an early start of multiplayer play. However, an operation unit for leaving the room may be provided on the room details page of the guest terminal so that guest players can leave the room. Also, the room details page displayed on the host terminal may have an operation unit for intentionally disbanding the room.

[0089] As described above, when a player participates in an invited battle game by inputting a participation operation in the participation tab of the operation unit 54b, more specifically, when the player enters the invited room, all invitation information is deleted from the player terminal 1.

[0090] On the other hand, if entry to the room is not possible, the player is notified that entry to the room is not possible, and then the original game screen is displayed. At this time, the invitation information selected by the player is deleted, and the invitation information image 54 for which the participation tab was tapped is hidden. However, in this case, other invitation information is not deleted, so the invitation information images 54 corresponding to the invitation information not selected by the player can be displayed.

[0091] 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, if the battle game is resumed after being interrupted, the thumbnail image 52a is hidden.

[0092] As described above, the thumbnail image 52a remains displayed for 10 seconds after the invitation information is received, and then automatically disappears after 10 seconds have passed. Also, if the notification image 34 or the thumbnail image 52a is tapped while the thumbnail image 52a is displayed and the invitation information image 54 is displayed, the thumbnail image 52a also disappears.

[0093] For example, suppose that immediately after the invitation information is received and the thumbnail image 52a is displayed, the notification image 34 or the thumbnail image 52a is tapped, causing the invitation information image 54 to be displayed. If the battle game is resumed immediately thereafter and 10 seconds have not yet elapsed since the invitation information was received, the thumbnail image 52a may be displayed. Alternatively, if the battle game is resumed after the invitation information image 54 is displayed, the thumbnail image 52a may be displayed for a predetermined time after the battle game is resumed. Furthermore, when the invitation information image 54 is displayed, the thumbnail image 52a may be displayed simultaneously.

[0094] As described above, when invitation information is received during a battle game, the notification image 34 is displayed in a 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 if the notification image 34 displayed in the notification mode is tapped after the thumbnail image 52a disappears, the invitation information image 54 is displayed superimposed on the battle screen at the time of interruption, as shown in FIG. 6C , in the same manner as described above.

[0095] Furthermore, 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. Information about the interrupted battle game is displayed in the pause dialog 56. The pause dialog 56 also has an operation tab 42. When the operation tab 42 is tapped while the pause dialog 56 is displayed, the pause dialog 56 frames out toward the left side of the display 26, and the battle game is resumed.

[0096] Note that, when invitation information has not been received, the operation tab 42 is displayed in the upper left of the display 26 while the battle screen is being displayed. If the operation tab 42 is tapped at this time, a pause screen provided with a retire operation unit and a resume operation unit is displayed when the battle game is paused, as described above. In this way, if the operation tab 42 is tapped during the battle game, a pause screen is displayed, and if the operation tab 42 or the game information display unit 54a is tapped while the invitation information image 54 is being displayed after the battle game is paused, a pause screen different from the pause screen is displayed.

[0097] 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 retire operation section and a resume operation section.

[0098] As described above, the invitation information image 54 displays detailed information about the battle game to which the player has been invited, and so the display of the invitation information image 54 can be considered the opening of the invitation information. In other words, the invitation information is opened by tapping the notification image 34 or thumbnail image 52a in the notification mode. However, the invitation information is not opened when the thumbnail image 52a is displayed.

[0099] Furthermore, if the battle game is resumed without tapping the operation unit 54b after the invitation information image 54 is displayed, or if a pause screen is displayed, the invitation information remains held. In other words, an operation to transition the screen without deleting the invitation information after the invitation information image 54 is displayed is a hold operation, and if a hold operation is input, participation in the invited battle game is put on hold.

[0100] Next, a method for extracting target persons in the server 100 will be described, followed by a method for receiving and notifying invitation information in the player terminal 1.

[0101] (Method of selecting subjects) Fig. 7A is a diagram explaining priority points. Fig. 7B is a diagram explaining update conditions for priority points. The server 100 stores player information for each player (player ID). The player information includes various information necessary for playing the game, such as player experience points, player level, player rank, owned characters, followers, mutual followers, and party information.

[0102] The player information also includes priority information as information for extracting targets who will receive the invitation information. The server 100 accumulates the player information including the priority information for each player in the storage unit 118, and updates the priority information according to preset update conditions.

[0103] In this embodiment, priority points are provided as priority information. As shown in Fig. 7A, the priority points are set to a maximum value of 999 points and a minimum value of 0 points, and are updated within the range of 0 to 999. The priority points are set to an initial value of 100 points, and are updated to the initial value when a predetermined update condition is met.

[0104] When creating a room, if the random tab 48c is tapped, the server 100 randomly extracts from all players eligible to receive invitation information. At this time, the server 100 prioritizes players with higher priority points as eligible players. Therefore, the higher the priority points, the more likely a player is to receive invitation information.

[0105] The priority point update conditions are set as shown in Figure 7B. Specifically, when a target person receives invitation information, the priority points of that target person are decremented by "4." Furthermore, when the target person receives the invitation information and then taps the notification image 34 or thumbnail image 52a to display the invitation information image 54, the priority points of that target person are incremented by "1."

[0106] Furthermore, if a target person taps the participation tab on the operation unit 54b to perform a participation operation but is unable to participate in a multiplayer game, the target person's priority points will be increased by "4." Examples of situations where a target person is unable to participate in a multiplayer game include being unable to enter a room because it is currently playing or is full, and being unable to enter a room after entering it and the room being disbanded before the multiplayer game begins. Here, the target person's priority points are increased if they are unable to participate in a multiplayer game. However, instead, the target person's priority points may be increased if they are unable to enter a room, for example.

[0107] Also, if a multiplayer battle game ends normally (including an intermediate end due to retirement, a win, or a loss), and 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.

[0108] Furthermore, when a room is created as the host player, the host player's priority points are decremented by "4." At this time, if the random tab 48c is tapped to randomly select a target person to receive the invitation information, the host player's priority points are incremented by "1." Furthermore, when a multiplay session is started, the host player's priority points are incremented by "1."

[0109] Furthermore, when a multiplayer battle game ends in victory or defeat, priority points will be increased by "3" for all players whose damage to enemy characters (hereinafter referred to as "damage dealt") is 20% or more of the total damage.

[0110] According to the above update conditions, for example, if a target player attempts to participate in a multiplayer game but is unable to do so, their priority points will increase by "1" compared to the level before receiving the invitation information due to the receipt of the invitation information (-4), the opening of the invitation information (+1), and the inability to participate in the multiplayer game (+4). This makes it easier for players who attempted to participate in a multiplayer game but were unable to do so to receive an invitation information. Furthermore, if the priority points exceed the initial value and the multiplayer battle game ends normally, they will be reset to the initial value. This ensures that many players have an equal opportunity to receive an invitation information.

[0111] Furthermore, if a guest player participating in a multiplayer game deals damage that exceeds 20% of the total damage, their priority points will be zero, based on the level before joining the game, due to the receipt of the invitation information (-4), the opening of the invitation information (+1), and the damage dealt being 20% ​​or more (+3). On the other hand, a guest player who deals damage that is less than 20% of the total damage will have their priority points subtracted by 3, based on the level before joining the game, due to the receipt of the invitation information (-4) and the opening of the invitation information (+1). In other words, uncooperative guest players in a multiplayer game will have a lower priority and will be less likely to be selected as a target player. In this way, by changing the priority points based on the game results during the online game, cooperative players will be relatively more likely to be selected as a target player.

[0112] Furthermore, the host player's priority points are deducted by 4 when they create a room, but once they start multiplayer and deal 20% or more of their total damage, their priority points will not decrease. Specifically, if a target is randomly selected, the priority points will increase by 1 from the level before the room was created, based on the following: room creation (-4), randomly selected target (+1), multiplayer start (+1), and damage dealt of 20% or more (+3). Furthermore, if the target is set as a follower or mutual follower, the priority points will be zero, based on the level before the room was created, based on the following: room creation (-4), multiplayer start (+1), and damage dealt of 20% or more (+3). This means that if a host player appropriately starts multiplayer and plays cooperatively, they will be considered a good player, and they will also have the opportunity to participate in multiplayer as a guest player.

[0113] On the other hand, if a room is created but multiplayer is not started, for example, by creating a room (-4) and randomly selecting a target (+1), the priority points will be reduced by 3 from the level before the room was created. Also, 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 (+1), and starting multiplayer (+1), the priority points will be reduced by 2 from the level before the room was created. This makes it more difficult for players who abandon rooms, intentionally disband rooms, or uncooperative players to participate in multiplayer as guest players.

[0114] According to this embodiment in which the update conditions are set as described above, invitation information is more likely to reach players who are considered to be cooperative or excellent, thereby realizing appropriate matching. The following describes the processing of the server 100 when selecting a target player from among all players.

[0115] (Server 100 list update process) FIG. 8 is a first diagram illustrating the list update process. 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. The server 100 performs a player information update process that updates the player information in the player information storage unit 160 every time communication is performed with a player terminal 1. The storage unit 118 also has an extraction list. The server 100 constantly performs a list update process that updates the extraction list based on the player information in the player information storage unit 160.

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

[0117] In addition, 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, the description will be given using an extraction list listing players with player ranks 11 to 20.

[0118] In the extraction list, a player with a higher priority point is listed in a storage area with an address assigned with a higher priority. For example, suppose that the highest priority point is "165" among players with player ranks 11 to 20. Also, suppose that there are five players with the highest priority points. In this case, the player information of the player with a priority point of "165" is set in the storage areas with addresses 1 to 5. Note that if there are multiple players with the same priority point, the address (priority) is determined according to a predetermined condition. In this way, in the list update process, players are listed in the extraction list in descending order of priority point based on the player information in the player information storage unit 160.

[0119] FIG. 9 is a second diagram illustrating the list update process. For example, assume that request information requesting the creation of a room and the sending of invitation information is transmitted from one of the player terminals 1. The request information is provided so as to be identifiable for each of the follower tab 48a, the mutual follower tab 48b, and the random tab 48c. When the server 100 receives the request information, it performs a room setting process to create and set up a room. At this time, if the received request information is request information for the random tab 48c, the target users are set in the list update process as follows.

[0120] 9, the invitation information is set in a predetermined number of storage areas (here, 100) in order of priority, starting from the storage area with the address with the highest priority. However, the storage area in which the invitation information is set is determined based on the status flag.

[0121] Specifically, the status flag identifies the reception status of the invitation information, and here, six reception statuses are identified: "Receive 1," "Receive 2," "Receive 3," "Settable," "Receiving Available," and "Not Receiving." The reception statuses "Receive 1," "Receive 2," and "Receive 3" indicate that the target terminal has received the invitation information. More specifically, "Receive 1" indicates that one invitation information has been received, "Receive 2" indicates that two invitation information has been received, and "Receive 3" indicates that three invitation information has been received.

[0122] As described above, one player terminal 1 can receive and store a maximum of three pieces of invitation information. Therefore, the reception statuses "reception 1" and "reception 2" indicate that new invitation information can be set. On the other hand, the reception status "reception 3" indicates that new invitation information cannot be set.

[0123] The reception status "Settable" indicates that the invitation information can be set. When the area in the storage area where the status flag is stored is blank (when the status flag is off), the reception status becomes "Settable". Furthermore, the reception status "Receiptable" indicates that reception of the set invitation information is permitted when there is a reception confirmation from the player terminal 1 set for the target person (hereinafter referred to as the "target person terminal"). Furthermore, the reception status "Not Receiptable" indicates that reception of the set invitation information is restricted when there is a reception confirmation from the target person terminal.

[0124] The server 100 searches the storage areas with the reception statuses "reception 1," "reception 2," and "setting possible" in order from the storage areas assigned with addresses with higher priority, and sets the invitation information. For example, in the state shown in FIG. 8, the status flags are blank in all storage areas with addresses 1 to 100. In this state, when request information for the random tab 48c is received from the player terminals 1 of players with player ranks of 11 to 20, the invitation information is set in the storage areas with addresses 1 to 100, as shown in FIG. 9.

[0125] Furthermore, a status flag is set in the storage area in which the invitation information is set. At this time, a status flag indicating "receive possible" is set in the storage area with the highest priority point among the storage areas in which the invitation information is set. Furthermore, a status flag indicating "receive impossible" is set in the other storage areas in which the invitation information is set. Furthermore, a wait time is set in each storage area in which the status flag "receive impossible" is set.

[0126] This wait time is the time it takes for the reception status to change from "receiving not possible" to "receiving possible." In other words, if the "receiving not possible" status flag is set, the status flag will change to "receiving possible" after the wait time has elapsed. Each storage area is grouped by priority point, and the same wait time is set for storage areas classified into the same group. Furthermore, the wait time is set shorter for groups with relatively high priority points than for groups with relatively low priority points.

[0127] In the example shown in Fig. 9, the wait time is set to 5 seconds for the group with a priority point of "164," and 10 seconds for the group with a priority point of "163." In this way, the wait time becomes shorter as the priority point becomes higher, and longer as the priority point becomes lower.

[0128] FIG. 10 is a third diagram illustrating the list update process. Assume that, for example, five seconds have passed after the invitation information, status flag, and wait time are set as shown in FIG. 9. As described above, the wait time is set to five seconds in the storage areas of addresses 6 to 99. When this five-second wait time has passed, the status flags in the storage areas of addresses 6 to 99 are switched to "receiveable," as shown in FIG. 10. Since the wait time in the storage area of ​​address 100 was initially set to 10 seconds, the reception status remains "receive unavailable," and the wait time is updated to five seconds.

[0129] As described above, when the reception status is "reception not possible," the player terminal 1 cannot receive the invitation information even though the invitation information has been set. In other words, even if the player terminal 1 confirms reception when the invitation information has been set, the player terminal 1 will not receive the invitation information. In this way, when the server 100 sets the invitation information to set the target player, the higher the priority points, the earlier the player can receive the invitation information. As a result, the higher the priority point, the more likely the player can participate in multiplay.

[0130] Furthermore, in the above state, suppose that new request information for the random tab 48c is sent from another player terminal 1. In this case, as shown in FIG. 10, invitation information is set in the storage areas of addresses 101 to 200. Note that the priority points of all of the storage areas of addresses 101 to 200 are 163. Therefore, in this case, the status flag of "receiveable" is set in all of the storage areas of addresses 101 to 200.

[0131] FIG. 11 is a fourth diagram illustrating the list update process. For example, in the state shown in FIG. 10, it is assumed that the reception of the invitation information is confirmed from the target terminals set as the target players in the storage areas of Address 1 and Address 3. In this case, the target terminals of both players receive the invitation information set in the storage areas. When the invitation information is received, the server 100 switches the status flag from "Ready to Receive" to "Receive 1," as shown in the upper diagram of FIG. 11.

[0132] Furthermore, as described above, when a target person receives the invitation information, the target person's priority points are decremented by "4." The server 100 updates the priority points to "161" in the storage areas of addresses 1 and 3. The server 100 then performs a sorting process 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 an address (storage area) with a lower priority, as shown in the lower diagram of FIG. 11.

[0133] The server 100 counts the number of invitation information pieces received for each player terminal 1. As described above, a player terminal 1 with a status flag of "reception 1" or "reception 2" can receive further invitation information. For example, when new invitation information is set for a player terminal 1 with a status flag of "reception 1," the status flag is updated to "reception possible" or "reception not possible." Thereafter, when the newly set invitation information is received, the number of invitation information pieces received is updated to "2," and the status flag is updated to "reception 2."

[0134] Furthermore, when the delete tab of the operation unit 54b is tapped on the player terminal 1 after receiving the invitation information, the deletion information is transmitted to the server 100. When the server 100 receives the deletion information, it 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, for example, when the multiplay ends or the room disappears.

[0135] When the invitation information is deleted, the number of received invitation information pieces is decremented by "1." For example, when deletion information is received from a player terminal 1 whose status flag is "Received 2," the status flag is updated to "Received 1." When deletion information is received from a player terminal 1 whose status flag is "Received 1," the status flag is updated to blank.

[0136] When request information for the follower tab 48a is transmitted, the invitation information is set in the storage area of ​​the player who is set as a follower, as will be described in detail later. When request information for the mutual follower tab 48b is transmitted, the invitation information is set in the storage area of ​​the player who is set as a mutual follower.

[0137] According to the list update process described above, players who are highly motivated to participate in multiplayer games are more likely to receive invitation information. By having players who are highly motivated to participate receive invitation information, the time it takes to start multiplayer games is reduced.

[0138] Furthermore, in this embodiment, the invitation information is received according to the game play status at the player terminal 1. Specifically, the reception of the invitation information is notified when a player is playing a battle game (single play) or in a situation where it is considered that the player is gazing at the screen to play the game. In other words, the player terminal 1 notifies the reception of the invitation information in a situation where it is considered that the player is highly motivated to participate in multiplayer play and highly responsive to the invitation. This reduces the time it takes for players to gather to participate in multiplayer play, and shortens the time it takes for multiplayer play to start.

[0139] (Play status of player device 1) FIG. 12A is a diagram illustrating the play state of the player terminal 1. FIG. 12B is a diagram illustrating the timing of confirming receipt of invitation information. The player terminal 1 updates the play state based on the game play status and the reception status of the invitation information. 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.

[0140] When the player terminal 1 receives invitation information, one of the three state storage units is assigned to the received invitation information. The player terminal 1 stores the invitation information in the assigned state storage unit. Each state storage unit stores a play state. The play state is updated separately in each state storage unit based on whether or not the invitation information has been assigned.

[0141] As described above, a maximum of three thumbnail images 52a are displayed in the thumbnail display area 52. In other words, three display positions at which the thumbnail images 52a are displayed are defined in the thumbnail display area 52. Each of the three state storage units is associated with one of the display positions in the thumbnail display area 52 at which the thumbnail image 52a is displayed.

[0142] For example, the first state memory unit 82 is associated with a first display position that is the uppermost position in the thumbnail display area 52. The second state memory unit 84 is associated with a second display position that is the center of the thumbnail display area 52. The third state memory unit 86 is associated with a third display position that is the lowermost position in the thumbnail display area 52. If, for example, invitation information is received and the first state memory unit 82 is assigned to this invitation information, the thumbnail image 52a will be displayed at the first display position.

[0143] As shown in Fig. 12A, in the player terminal 1, the play status managed by each status storage unit is one of four statuses: available for receipt, unopened, opened, and participating. That is, the play status is set to one of the above four play statuses in the status storage unit. The player terminal 1 executes processing related to receiving invitation information based on the set play status.

[0144] Each play state is associated in the state storage unit with whether or not new invitation information can be assigned. If the play state is set to a receivable state in the state storage unit, the player terminal 1 can receive invitation information from the server 100. In other words, among the play states, the receivable state can be said to be an allowed state in which the assignment of new invitation information is permitted.

[0145] On the other hand, invitation information is not assigned to a state storage unit in which the play state is set to the unopened state, opened state, or participating state. In other words, the unopened state, opened state, and participating state among the play states can be said to be impossible states in which invitation information cannot be assigned.

[0146] Therefore, if the play state in all three state storage units is either the unopened state, the opened state, or the participating state, the player terminal 1 cannot receive invitation information. On the other hand, if the play state in at least one of the three state storage units is the receiving state, the player terminal 1 can receive invitation information.

[0147] For example, suppose that a player is set as a target player in the server 100, and invitation information for the player is set in the server 100. At this time, if the player terminal 1 has a state storage unit in which the play state is set to a receiving state, the player terminal 1 receives the invitation information from the server 100.

[0148] On the other hand, even if the invitation information is set in the server 100, if the play status is set to the unopened status, the opened status, or the participating status in all the status storage units, the player terminal 1 will not receive the invitation information from the server 100. In other words, if the play status is set to any one of the unopened status, the opened status, or the participating status in all the status storage units, the player terminal 1 will not execute reception confirmation of the invitation information.

[0149] Although a detailed explanation will be omitted, even if the play status is permitted, the player terminal 1 may not receive the invitation information depending on the set invitation information. For example, suppose that the player taps the delete tab on the operation unit 54b to delete the invitation information. In other words, suppose that the player declines to participate in the battle game to which he / she was invited. In this case, the player will not receive invitation information inviting participation in the same type of battle game as the battle game in which he / she declined to participate for a predetermined time after the deletion information is sent.

[0150] In this way, by not receiving invitation information that is unlikely to result in the player participating, the possibility of the player feeling annoyed is reduced. As described above, when the play state is in the permitted state, it is possible in principle to receive invitation information, but depending on the content of the invitation information, reception of some invitation information may be restricted.

[0151] 12A, each of the above play states has a setting condition. The player terminal 1 determines whether the setting condition is met, and sets the play state for each state storage unit based on the determination result.

[0152] The conditions for being in a state where invitation information is not stored and the user is not currently in a multiplayer room are set as the conditions for being in a receiving state.

[0153] The unopened state is set as a setting condition that invitation information is stored, that the invitation information image 54 is not displayed, and that the invitation information is unopened. Note that an expiration time is set in advance for the invitation information. After the invitation information is received, if the expiration time has passed, the invitation information is deleted from the player terminal 1. If the play status remains in the unopened state and the expiration time has passed, the invitation information is deleted, and the play status is updated to the receiveable state.

[0154] The opened state is set as a setting condition that the invitation information is stored and that the invitation information image 54 has been displayed. The opened state is set when the invitation information image 54 is being displayed and when the invitation information image 54 is hidden after a hold operation is input. The hold operation is an operation in which the invitation information image 54 is hidden after the invitation information image 54 is displayed without operating the join tab or delete tab on the operation unit 54b.

[0155] Even after the play status has been updated from unopened to opened, if the valid time has elapsed without the Join tab or Delete tab being operated, the invitation information will be deleted in the same manner as above. In this case, the play status will be updated from opened to available in the status storage unit where the deleted invitation information was stored.

[0156] The participation status is set as a condition that the player is currently in a multiplayer room.

[0157] Here, the play status is updated for each status storage unit, but the participation status is set commonly in the three status storage units. For example, if two invitations are received but the invitation information image 54 is not displayed, the play status will be unopened in two status storage units and ready to receive in one status storage unit.

[0158] In this state, when the notification image 34 or thumbnail image 52a in the notification mode is tapped, two invitation information images 54 are displayed, and the play status is updated to opened in the two status storage units. Then, assume that a join operation is input into the operation unit 54b of one of the invitation information images 54, and the user enters a multiplayer room. In this case, the play status is updated to participating in all three status storage units. After that, when the multiplayer game ends, the play status is updated to available to receive in all three status storage units.

[0159] In this way, the participation state of the play state is always set simultaneously in all three state storage units. On the other hand, if the play state in any of the three state storage units is not the participation state, the play state in the three state storage units will be set to either the available state, the unopened state, or the opened state.

[0160] When the play state of at least one state storage unit is set to the permitted state, that is, when there is at least one state storage unit in which the play state is set to the receiveable state, the player terminal 1 confirms receipt of the invitation information with the server 100. At this time, if invitation information for the player terminal 1 itself has been set, the player terminal 1 receives the set invitation information.

[0161] When the invitation information is received, if there is a status storage unit whose play status is set to a receiveable state, that status storage unit is assigned to the received invitation information. As a result, the play status of the status storage unit to which the invitation information is assigned is updated from a receiveable state to an unopened state.

[0162] Of the three state storage units, the first state storage unit 82 has the highest priority for allocating invitation information, and the third state storage unit 86 has the lowest priority for allocating invitation information. Therefore, for example, if invitation information is received when the play states of all three state storage units are set to a receive-ready state, the invitation information is allocated to the first state storage unit 82.

[0163] Here, the reception of the invitation information is confirmed at the player terminal 1 as shown in Fig. 12B. That is, when a battle screen is displayed on the display 26 of the player terminal 1, the reception of the invitation information is confirmed at 15-second intervals. However, when the display 26 transitions from a normal screen (a screen other than the battle screen) to the battle screen, the timing at which the reception of the invitation information is first confirmed after the screen transition is randomly determined by lottery between 1 and 15 seconds.

[0164] Furthermore, when a normal screen (a screen other than the battle screen) is displayed on the display 26 of the player terminal 1, the receipt of the invitation information is confirmed at 10-second intervals. However, when the display 26 transitions from the battle screen to the normal screen, when the normal screen transitions to another normal screen, or when a page transition occurs within the normal screen, the timing for the first receipt confirmation of the invitation information after the screen transition is randomly determined by lottery between 1 and 10 seconds.

[0165] As described above, by randomly determining the timing for first confirming receipt of the invitation information after a screen transition, it is possible to prevent the player from performing an operation such as transitioning screens just to receive the invitation information, thereby suppressing unnecessary communication with the server 100 and reducing the load on the server 100.

[0166] Furthermore, while the battle screen is displayed, the interval between confirmations of the receipt of invitation information is set longer than when the normal screen is displayed, which prevents unnecessary battle games from being played for the purpose of receiving invitation information, thereby preventing an increase in the load on the server 100.

[0167] Next, a description will be given of the communication processing between the player terminal 1 and the server 100 for executing the above multiplay. Note that here, the basic communication processing for progressing the game and an example of the main communication processing related to multiplay will be described, and a description of other processing will be omitted.

[0168] (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. In the following description, when there is no need to distinguish between the host terminal, the guest terminal, and the target terminal, the processing in the player terminal 1 will be referred to as Pn (n is an arbitrary integer). Furthermore, the processing in the server 100 will be referred to as Sn (n is an arbitrary integer). When a player starts a game application in the player terminal 1 (P1), login information is transmitted from the player terminal 1 to the server 100. Upon 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 player information corresponding to the identified player terminal 1 from the storage unit 118.

[0169] Furthermore, if the player terminal 1 has a state storage unit in which the play state is set to a reception-enabled state, the player terminal 1 confirms receipt of the invitation information at predetermined time intervals (P2). Here, the player terminal 1 transmits the reception confirmation information to the server 100. Upon receiving the reception confirmation information, the server 100 searches the extraction list to determine whether or not there is invitation information for the player terminal 1 (S2). At this time, if the invitation information is set and the reception status is set to "receive-enabled," 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 the player that the invitation information has been received (P3).

[0170] Also, assume that the single play tab 40a is tapped on the play content selection page (see FIG. 4A) on the player terminal 1, and an operation to start single play is performed (P4). In this case, start information is transmitted from the player terminal 1 to the server 100. This start information includes party information selected by the player, information on the type of battle game, etc. In response to the input of the start information, the server 100 performs a battle game start process required to start the battle game (S3).

[0171] 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 into the memory 112. The server 100 also sets the player terminal 1 so that it can receive data necessary for executing the battle game.

[0172] Then, in the player terminal 1, a battle game start process required to start the battle game is also performed (P5). Here, for example, an area in 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 into the memory 12.

[0173] Once preparation for the battle game is completed as described above, a battle game control process for controlling the single-play battle game is performed simultaneously in both the player terminal 1 and the server 100 (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, and the number of frames per second is, for example, 30 to 60. Therefore, during the battle game, information is updated approximately every 16 ms to 33 ms in the player terminal 1 and the server 100.

[0174] Furthermore, in the update process, update information is transmitted and received between the player terminal 1 and the server 100. Here, the update process and the transmission and reception of the update information are performed on a frame-by-frame basis, but the update process and the transmission and reception of the update information may be performed in cycles shorter or longer than the frame-by-frame basis. Also, during a single-play battle game, confirmation of receipt of invitation information at the player terminal 1 (P7), a search for the invitation information at the server 100 (S5), and notification of receipt of the invitation information at the player terminal 1 (P8) may be periodically performed.

[0175] Then, when the conditions for ending the battle game are met, an ending process for ending the battle game is performed in each of the player terminal 1 and the server 100 (P9, S6). In the ending process (P9) of the player terminal 1, for example, a result screen is displayed on the display 26. In addition, in the ending process (S6) of the server 100, various pieces of player information, such as items acquired in the battle game, player experience points, character experience points, etc., are updated.

[0176] 14 is a sequence diagram illustrating the processing of the player terminals 1 and the server 100 when multiplay is performed. In the following description, the processing in the host terminal is represented as HPn (n is any integer), and the processing in the target terminal and guest terminal is represented as GPn (n is any integer).

[0177] Assume that the room creation tab 46 is tapped on the player terminal 1 (host terminal) to input a request operation (HP10). When the request operation is input, the player terminal 1 (host terminal) transmits request information to the server 100, requesting the creation of a room and the 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 operation section, etc.

[0178] When the server 100 receives the request information, it performs a point update process (indicated as UPDATE in the drawing) in the player information storage unit 160 to update the priority points. Here, the priority points of the host player who transmitted the request information are decremented by "4." Furthermore, as will be described in detail 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 in the player information storage unit 160. Furthermore, in the extraction list, a sorting process is performed based on the updated priority points.

[0179] Furthermore, upon receiving the request information, the server 100 performs a room setting process to create and set up a room (S10). Here, a processing area for executing multiplay, i.e., a room, is secured, and the various information included in the request information is stored in this room. Also, a room number for the created room is set. The host terminal receives the room setting information set in the room setting process, and displays a room details page on the display 26 (HP11).

[0180] The server 100 also sets the target person (S11). Here, the invitation information, status flag, and counter value of the wait counter are set in the extraction list, and the target person is set. Thereafter, when the target person's terminal confirms receipt of the invitation information (GP10), the receipt confirmation information is sent to the server 100. Upon receiving the receipt confirmation information, the server 100 searches to see if invitation information has been set for the target person (S12). Here, since the invitation information has been set, the server 100 updates the target person's reception status (status flag) to "received." The server 100 also performs a point update process, subtracting "4" from the priority points of the target person who received the invitation information.

[0181] When the target user terminal receives the invitation information, it displays the notification image 34 in a notification mode and also displays the thumbnail image 52a to notify the user that the invitation information has been received (GP11). The target user terminal also determines a state storage unit to be assigned to the received invitation information and stores the invitation information. At this time, it also updates the play state of the state storage unit that stores the invitation information to an unopened state (GP12). Thereafter, when the target user taps the notification image 34 or the thumbnail image 52a, the target user terminal displays the invitation information image 54 (GP13). When the invitation information image 54 is displayed, opening information is sent to the server 100. When the server 100 receives the opening information, it performs a point update process. Here, the target user's priority points are incremented by "1". Furthermore, the target user terminal also updates the play state of the state storage unit to which the invitation information is assigned to an opened state (GP14).

[0182] Thereafter, when the participant tab in the operation section 54b of the invitation information image 54 is tapped on the target user's terminal, participation information is sent from the target user's terminal to the server 100 (GP15). The participation information includes information related to the party set by the target user. Upon receiving the participation information, the server 100 determines whether entry to the room is permitted, and if entry to the room is permitted, updates the room information (S13). Here, the server 100 is set so that the updated room information (room update information) is received by the host terminal and the target user's terminal.

[0183] 14 shows only one target terminal (guest terminal), the same processing is performed on multiple target terminals (guest terminals) for one room. Therefore, when any player enters a room, the player terminals 1 of all players who have entered the room will receive the room update information.

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

[0185] Thereafter, when the start tab 50 on the room details page is tapped on the host terminal to input an operation to start multiplayer (HP13), start information is sent to the server 100. In response to the input of the start information, the server 100 performs a point update process. Here, the host player's priority points are incremented by "1."

[0186] The host terminal, server 100, and guest terminal each perform the above-described battle game start process (not shown), after which a multiplay control process for controlling the multiplay is performed simultaneously in parallel (HP14, S14, GP18). In this multiplay control process, an update process for updating various information is repeatedly executed on a frame-by-frame basis. In this update process, update information is sent and received between the host terminal, guest terminal, and server 100. Then, when the end condition for the battle game is met, an end process for ending the battle game is performed in each of the host terminal, guest terminal, and server 100 (HP15, S15, GP19).

[0187] At the end of the multiplayer game, the server 100 calculates the damage dealt out of the total damage for each player who participated in the multiplayer game (S16). Then, based on the calculated damage dealt, a point update process is performed. Here, priority points are increased by "3" for players whose damage dealt is 20% or more of the total damage. Meanwhile, at the end of the multiplayer game, the guest terminal deletes the invitation information from all state storage units, and the play state is updated to a receiving state (GP20).

[0188] FIG. 15 is a sequence diagram illustrating the processing of the player terminal 1 and the server 100 when participation in a multiplay is not possible. Note that in FIG. 15, the processing up to the time when participation information is input from the target user terminal is the same as that in FIG. 14, and therefore the description will be omitted. As described above, when a participation operation is input from the target user terminal, the participation information is transmitted to the server 100 (GP15). Upon receiving the participation information, the server 100 determines whether entry into the room is possible. At this time, if entry into the room is not possible, the server 100 sets participation impossible information indicating that entry into the room is not possible. At this time, the server 100 also performs point update processing and adds "4" to the priority points of the target user.

[0189] When the target user terminal receives the participation impossible information, it 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). The target user terminal also deletes the invitation information for which the participation operation has been performed and updates the play status in the status memory unit from which the invitation information has been deleted to a receiving status (GP23).

[0190] FIG. 16 is a sequence diagram illustrating the processing of the player terminal 1 and the server 100 when participation in a multiplay game is refused. Note that in FIG. 16, the processing up to the time when deletion information is input from the target user terminal is the same as that in FIG. 14, and therefore the description thereof will be omitted. When the delete tab of the operation unit 54b in the invitation information image 54 is tapped on the target user terminal, the deletion information is transmitted from the target user terminal to the server 100 (GP24). Furthermore, on the target user terminal, the invitation information is deleted from the status storage unit to which the deleted invitation information is assigned, and the play status is updated to a receiving status (GP25).

[0191] When the server 100 receives the deletion information, it updates the reception status (status flag) of the target terminal that sent the deletion information (S17). Here, the number of receptions of the invitation information is subtracted, and the status flag is updated, for example, from "received 1" to blank, or from "received 3" to "received 2."

[0192] Next, we will explain the functional configuration of the player terminal 1 and the specific processing in the player terminal 1. Note that, hereinafter, we will explain the configuration and processing related to the invitation information, and will omit explanations of the configuration and processing unrelated to the invitation information.

[0193] (Functional configuration of player terminal 1) 17 is a diagram illustrating the configuration of the memory 12 in the player terminal 1 and its functions as a computer. The memory 12 is provided with a program storage area 12a and a data storage area 12b. The CPU 10 stores a terminal-side game control program (module) in the program storage area 12a when a multiplay session starts or before the multiplay session starts.

[0194] 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 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 timing program 76. Note that the programs listed in Figure 17 are just an example, and the terminal-side game control program includes many other programs.

[0195] The data memory area 12b is provided with the following memory units for storing data: a game information memory unit 80, a first state memory unit 82, a second state memory unit 84, and a third state memory unit 86. Note that the above-mentioned memory units are merely examples, and the data memory area 12b is provided with many other memory units.

[0196] The CPU 10 runs each program stored in the program storage area 12a and updates data in each storage unit in the data storage area 12b. The CPU 10 runs each program stored in the program storage area 12a, causing the player terminal 1 (computer) to function as a terminal game control unit 1A. The terminal game control unit 1A includes a game execution unit 60a, a battle game execution unit 62a, a request information transmission unit 64a, a play status 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 timing unit 76a.

[0197] Specifically, the CPU 10 runs a game execution program 60, causing the computer to function as a game execution unit 60a. Similarly, the CPU 10 runs 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 timing program 76, causing them to function as a battle game execution unit 62a, a request information transmission unit 64a, a play status 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 timing unit 76a, respectively.

[0198] The game execution unit 60a controls the progress of games other than the battle game, such as party organization and strengthening of ally characters, based on the player's operations. Every time an operation is input to the player terminal 1, the game execution unit 60a updates the game screen and transmits information corresponding to the operation to the server 100. Furthermore, when information related to the game is updated, the game execution unit 60a updates the information in the game information storage unit 80.

[0199] The battle game executing unit 62a is responsible for all control for executing the battle game. For example, the battle game executing unit 62a transmits information to the server 100 based on operations input to the player terminal 1, and receives various information from the server 100. The battle game executing unit 62a also updates the battle screen based on operations input to the player terminal 1 and information received from the server 100. That is, the battle game executing unit 62a executes single play or multiplay with other player terminals 1. Furthermore, when the battle game ends normally, the battle game executing unit 62a updates the information in the game information storage unit 80.

[0200] That is, the game executing unit 60a and the battle game executing unit 62a function as a display control unit that displays the game screen during play.

[0201] When any of the operation sections of the follower tab 48a, the mutual follower tab 48b, and the random tab 48c is tapped, the request information transmitting section 64a transmits to the server 100 a request signal corresponding to the operation section.

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

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

[0204] That is, the invitation information receiving unit 68a functions as a receiving unit that can receive multiple pieces of invitation information inviting participation in any of multiple types of invitation games from an external device.

[0205] When the notification unit 70a receives invitation information, it displays the notification image 34 in the notification mode and the thumbnail image 52a. The notification unit 70a also switches the notification image 34 between the notification mode and the non-notification mode based on whether the invitation information is stored in the first state memory unit 82, the second state memory unit 84, and the third state memory unit 86, i.e., whether the invitation information has been received.

[0206] That is, the notification unit 70a displays the thumbnail image 52a as a notification image corresponding to the received invitation information while maintaining the display of the game screen being played. Furthermore, when multiple invitation information pieces are received, the notification unit 70a functions as a notification unit that displays the thumbnail image 52a for each invitation information piece.

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

[0208] In other words, when a player inputs an operation to select the thumbnail image 52a as an announcement image, the invitation information image display unit 72a functions as a predetermined image display unit that displays game information regarding the inviting game corresponding to the thumbnail image 52a and a predetermined image that includes at least an operation unit that accepts an operation to participate in the inviting game.

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

[0210] The timer 76a measures the validity period of the invitation information, the time elapsed since the deletion operation was input, the time since the screen was changed, and the like.

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

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

[0213] Furthermore, when the terminal-side game control unit 1A receives room setting information (YES in P110-5), it displays a room details page on the display 26 (P110-6). Furthermore, when the terminal-side game control unit 1A receives 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).

[0214] Furthermore, when the start tab 50 is tapped to input a start operation (YES in P110-9), the terminal-side game control unit 1A transmits start information to the server 100 (P110-10) and waits until multiplay starts (P110-11). Note that when multiplay can start, the multiplay battle game is controlled in the above-mentioned battle game execution process (P101).

[0215] FIG. 20 is a flowchart illustrating an example of invitation information reception processing in the player terminal 1. When the screen on the display 26 changes (YES in P120-1), the timer 76a checks the screen being displayed on the display 26 (P120-2) and determines an initial counter value by lottery (P120-3). The initial counter value indicates the interval between confirmations of reception of invitation information. Here, if a normal screen is displayed, a value corresponding to any one of 1 to 10 seconds is determined as the initial counter value, and if a battle screen is displayed, a value corresponding to any one of 1 to 15 seconds is determined as the initial counter value. The timer 76a stores the determined initial counter value in a predetermined storage section of the data storage area 12b, and also sets it in the reception standby counter (P120-4).

[0216] Furthermore, if the play status is unopened or opened in any of the first status memory unit 82, the second status memory unit 84, and the third status memory unit 86 (YES in P120-5), the timing unit 76a decrements the counter value of the validity time counter that counts the validity time of the invitation information (P120-6).

[0217] If there are multiple state storage units with the play status in the unopened or opened state, the processes from P120-6 to P120-8 are executed for each of the multiple state storage units. Therefore, a valid time counter is provided for each state storage unit. If the counter value of the valid time counter is updated to 0 (YES in P120-7), the play status update unit 66a deletes the invitation information from the state storage unit corresponding to this valid time counter and updates the play status to available for receipt (P120-8).

[0218] Also, although not shown in the figure, if the play status is not in a receive-ready state in all status memory units until the play status is updated to a receive-ready state in P120-8, the initial counter value is determined based on the screen being displayed on the display 26, and set in the receive standby counter, as described above.

[0219] Furthermore, if the play state is a receiving-enabled 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-9), the timing unit 76a decrements the counter value of the reception standby counter (P120-10). Then, when the counter value of the reception standby counter becomes 0 (YES in P120-11), the timing unit 76a resets the reception standby counter to the initial counter value stored in the initial value storage unit. Furthermore, the invitation information receiving unit 68a executes invitation information confirmation processing (P121).

[0220] 21 is a flowchart illustrating an example of invitation information confirmation processing in the player terminal 1. The invitation information receiving unit 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 stores the received invitation information in any one of the first state storage unit 82, the second state storage unit 84, or the third state storage unit 86 (P121-3).

[0221] If a predetermined time has not elapsed since the deletion operation was input, the invitation information receiving unit 68a will not receive invitation information relating to the same type of battle game as the deleted invitation information. Therefore, in this case, the invitation information receiving unit 68a performs processing assuming that there is no invitation information available for reception.

[0222] However, the invitation information receiving unit 68a may determine whether the received invitation information is of the same type as the deleted invitation information if a predetermined time has not elapsed since the deletion operation was input after receiving all the invitation information. In this case, if the received invitation information is of the same type as the deleted invitation information, the invitation information may be discarded without being stored.

[0223] Furthermore, the play status update unit 66a updates the play status of the status storage unit that stores the invitation information to an unopened status (P121-4). Furthermore, the timing unit 76a sets a predetermined value in the valid time counter (P121-5). Furthermore, the notification unit 70a displays the notification image 34 in a notification mode and executes notification processing to display the thumbnail image 52a (P121-5). Note that here, the timing unit 76a sets the display time of the thumbnail image 52a in a timer. Although a detailed explanation will be omitted, the timer set here is decremented every frame, and when the timer reaches 0, the thumbnail image 52a is hidden.

[0224] 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 in P130-2) while invitation information is stored (YES in P130-1), the invitation information image display unit 72a displays the invitation information image 54 on the display 26 (P130-3). At this time, if there is a status storage unit in which the play status is set to an unopened state (YES in P130-4), the processing unit 74a transmits opening information to the server 100 (P130-5). Furthermore, the play status update unit 66a updates the play status to an opened state in all status storage units in which invitation information is stored (P130-6).

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

[0226] Thereafter, the processing unit 74a waits until it receives room update information or participation impossible information (P130-10). Then, when it receives room update information from the server 100 (YES in P130-11), the play status update unit 66a updates the play status to participating status (P130-12). The processing unit 74a also displays a room details page on the display 26 (P130-13). Here, the notification unit 70a also switches the notification image 34 to a non-display mode, and the invitation information image display unit 72a does not display the invitation information image 54.

[0227] On the other hand, if participation impossible information is received from the server 100 (NO in P130-11), the processing unit 74a displays an entry impossible screen on the display 26 (P130-14) and deletes the invitation information from the status storage unit (P130-15). Also, the invitation information image display unit 72a hides the invitation information image 54 corresponding to the deleted invitation information (P130-16). Furthermore, the play status update unit 66a updates the play status in the status storage unit from which the invitation information has been deleted to a receiving status (P130-17).

[0228] Furthermore, when the invitation information is stored and the invitation information image 54 is displayed, if the delete tab is tapped to input a delete operation (YES on P130-1, NO on P130-2, YES on P130-7, NO on P130-8, YES on P130-18 in FIG. 23), the processing unit 74a deletes the invitation information from the status storage unit (P130-19), and the play status update unit 66a updates the play status to a receiveable status (P130-20). Furthermore, the processing unit 74a transmits the deletion information to the server 100 (P130-21).

[0229] Furthermore, the invitation information image display unit 72a ends the display of the invitation information image 54 corresponding to the deleted invitation information (P130-22). Furthermore, the processing unit 74a sets a predetermined time in a deletion counter that measures the elapsed time since the deletion operation was input (P130-23). ​​The counter value of the deletion counter set here is decremented every frame until it reaches 0. If the counter value of this deletion counter is not 0, then in the above-mentioned P121-2, it is determined whether the receivable invitation information is of the same type as the deleted invitation information.

[0230] Furthermore, when the invitation information is stored and the invitation information image 54 is displayed, if a hold operation is input (YES on P130-1, NO on P130-2, YES on P130-7, NO on P130-8, NO on P130-18, YES on P130-28), the invitation information image display unit 72a will end the display of the invitation information image 54 (P130-29).

[0231] 24 is a flowchart illustrating an example of a multiplayer game ending process in a player terminal 1. When the multiplayer game ends (YES in P140-1), the battle game executing unit 62a displays a result screen on the display 26 (P140-2). At this time, if the player participates in the multiplayer game as a guest player (YES in P140-3), the invitation information receiving unit 68a erases the invitation information from all status storage units (P140-4). In addition, the play status updating unit 66a updates the play status in all status storage units to a status where the player can receive the invitation (P140-5).

[0232] Next, a description will be given of the functional configuration of the server 100 and specific processing in the server 100. Note that the following describes the configuration and processing related to setting of target persons who can receive invitation information, and descriptions of other configurations and processing will be omitted.

[0233] (Functional configuration of server 100) 25 is a diagram illustrating the configuration of the memory 112 in the server 100 and its functions as a computer. The memory 112 is provided with a program storage area 112a and a data storage area 112b. The CPU 110 stores a server-side game control program (module) in the program storage area 112a when a multiplay session starts or before the multiplay session starts.

[0234] 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. Note that the programs listed in Figure 25 are just examples, and the server-side game control program includes many other programs.

[0235] The data storage area 112b is provided with storage units for storing data, including 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. Note that the above storage units are merely examples, and the data storage area 112b is provided with many other storage units.

[0236] The CPU 110 runs each program stored in the program storage area 112a and updates data in each storage unit in the data storage area 112b. The CPU 110 runs each program stored in the program storage area 112a, causing the server 100 (computer) to function as a server-side game control unit 100A. 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.

[0237] Specifically, the CPU 110 runs a player information update program 140, causing the computer to function as a player information update unit 140a. Similarly, the CPU 110 runs a list update program 142, a terminal setting program 144, and a game execution program 146, causing them to function as a list update unit 142a, a terminal setting unit 144a, and a game execution unit 146a, respectively.

[0238] The player information update unit 140a updates the player information for each player stored in the player information storage unit 160 every time communication is established with a player terminal 1. In addition, the player information update unit 140a performs a point update process for updating the priority points in the player information storage unit 160.

[0239] The list update unit 142a 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 update unit 142a executes a sorting process to rearrange the storage areas in which player information is stored. The list update unit 142a also updates the invitation information, status flags, and wait counters in the extraction list.

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

[0241] The game execution unit 146a controls the progress of all games, including battle games, based on information input from the player terminals 1. The game execution unit 146a also stores various pieces of information updated during the game in the game information storage unit 164. Here, the game execution unit 146a stores the damage inflicted on enemy characters for each player in multiplay in the game information storage unit 164. However, the information stored in the game information storage unit 164 is not limited to this, and can be set appropriately based on the content of the game.

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

[0243] 27 is a flowchart illustrating an example of a request information receiving process in the server 100. When a follower is selected as a person to be invited to a 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 sets the invitation information, the status flag, and the counter value of the wait counter (hereinafter referred to as "invitation information, etc.") in the memory area of ​​the follower in the extraction list (S110-3).

[0244] When a mutual follower is selected as the person to be invited to the room, that is, when request information for the mutual follower tab 48b is received (YES in S110-1, NO in S110-2, YES in S110-4), the terminal setting unit 144a sets invitation information, etc. in the memory area of ​​the mutual follower in the extraction list (S110-5).

[0245] When setting invitation information to followers or mutual followers, it is not necessary to set the counter value of the wait counter. In other words, when followers or mutual followers are set as targets, all targets may receive the invitation information at the same time. Also, as in the case where targets are set randomly, the counter value of the wait counter may be set based on priority points.

[0246] If it is selected to randomly extract people to invite to the room, that is, if 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, etc. in the memory area of ​​the top 100 people in the extraction list whose reception status is "Received 1," "Received 2," or "Can be set" (S110-6).

[0247] Furthermore, if the target player is randomly set, the player information update unit 140a adds "1" to the priority points of the host player in the player information storage unit 160 (S110-8). Furthermore, if request information is received (YES in S110-1), the server-side game control unit 100A performs a room setting process to set a room (S110-8). Here, a room (a predetermined storage area) is set in the room information storage unit 166, and information related to the host player is stored in the room based on the request information. Furthermore, here, the server-side game control unit 100A sets the room information so that it can be received by the host terminal. Furthermore, 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).

[0248] 28 is a flowchart illustrating an example of information update processing in the server 100. When receiving reception confirmation information from a player terminal 1 (YES in S120-1), the server-side game control unit 100A searches the extraction list to determine whether invitation information for this player terminal 1 has been set (S120-2). At this time, if invitation information has been 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 performs invitation information output processing (S120-5). Here, the invitation information is set to be receivable by the player terminal 1 that sent the reception confirmation information.

[0249] The player information update unit 140a also subtracts "4" from the priority points of the target person stored in the player information storage unit 160 (S120-6). The list update unit 142a also updates the number of times that invitation information has been received for the player who has received the invitation information (S120-7). The list update unit 142a also updates the reception status (status flag) of the target person terminal in the extraction list to one of "reception 1," "reception 2," or "reception 3" based on the updated number of times that invitation information has been received.

[0250] Furthermore, when opening information is received from the player terminal 1 (target person terminal) (YES in S120-8), the player information update unit 140a adds "1" to the priority points of the target person stored in the player information storage unit 160 (S120-9).

[0251] Furthermore, if participation information is received from the player terminal 1 (target terminal) (YES in S120-10), and if entry to the room is permitted (YES in S120-11), the server-side game control unit 100A updates the room information in the room information storage unit 166 (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 terminal that sent the participation information) (S120-13).

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

[0253] Furthermore, when start information is received from the host terminal (YES in S120-16), the player information update 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 unit 100A executes a battle game start process to start the multiplay battle game (S120-18).

[0254] 29 is a flowchart illustrating an example of a multiplay termination process in the server 100. In the battle game execution process (S100), if the multiplay has ended normally other than midway (retirement) (YES in S130-1, NO in S130-2), the server-side game control unit 100A identifies the player who has dealt 20% or more of the total damage (S130-3). Note that in the battle game execution process (S100), the damage dealt by each player is stored in the game information storage unit 164 when the multiplay is being executed.

[0255] 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). Furthermore, at the end of the multiplay, the player information update unit 140a resets the priority points of all players whose priority points exceed the initial value to the initial value (set to 100) (S130-5).

[0256] 30 is a flowchart illustrating an example of a sorting process in the server 100. 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). The list update unit 142a also performs a sorting process to change the priority order based on the priority points of the extraction list (S140-2). As a result, the priority order of players is updated based on the priority points.

[0257] The list update unit 142a also performs a list information update process to update the information in the extraction list (S140-3). For example, the list update unit 142a updates the counter value of the wait counter, and updates the status flag from "receive not possible" to "receive possible" for the storage area where the counter value has been updated to 0. The list update unit 142a also updates the status flag from "receive possible" to "receive 1," "receive 2," or "receive 3" for the target person who has received the invitation information. Furthermore, the list update unit 142a updates the invitation information, status flag, and wait counter from the extraction list when the multiplay ends, when the room is disbanded, or when a predetermined time has passed since the invitation information was set.

[0258] While one embodiment has been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above embodiment. It is clear that a person skilled in the art can conceive of various modifications or alterations within the scope of the claims, and it is understood that these modifications also fall within the technical scope of the present invention.

[0259] The technical matters described in the above embodiment can be applied to any game field. Therefore, for example, the display content of the game screen on which the thumbnail image 52a and the invitation information image 54 are displayed is not particularly limited.

[0260] In the above embodiment, a case where an invitation to participate is made to a multiplayer battle game has been described. That is, the invitation game of the above embodiment is executed by communicating with the player terminals 1 of multiple players. However, the content of the invitation game to which an invitation to participate is made is not particularly limited. For example, the invitation game may be a game in which an invited player challenges a quest alone.

[0261] Furthermore, in the above embodiment, a server 100 is provided as an external device, and multiple 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 terminal 1 may have the above-described functions of the server 100, and any one of the player terminals 1 may function as an external device.

[0262] 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 sufficient that a notification image that corresponds to the received invitation information and that allows identification of part of the game information related to the inviting game is displayed while maintaining the display of the game screen being played. Furthermore, when multiple invitation information pieces are received, a notification image is displayed for each piece of invitation information.

[0263] Furthermore, in the above embodiment, when a thumbnail image 52a is tapped, 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. Furthermore, in the above embodiment, the invitation information image 54 has been described as an example of a predetermined image that is displayed when an operation to select an announcement image is input. However, the specific display content of the predetermined image is not limited as long as it includes at least more detailed game information than the announcement image and an operation unit that accepts an operation to participate in the invitation game when a player's operation to select an announcement image is input, and is displayed while maintaining the display of the game screen being played.

[0264] Furthermore, in the above embodiment, when the invitation information image 54 is displayed, the entire display 26 is darkened and the paused battle screen is displayed in a frozen state. 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 game in progress or the paused state when the operation tab 42 is tapped. In any case, the invitation information image 54 should be displayed in a state in which the game screen during play can be identified.

[0265] In the above embodiment, when the participation tab of the operation unit 54b is tapped, the processing unit 74a executes processing necessary to participate in the invitation game, such as transmitting participation information. However, the processing 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 to participate in the invitation game before transmitting the participation information.

[0266] In the above embodiment, the invitation information image 54 is hidden based on the input of a joining operation, a deletion operation, and a hold operation. However, the operations for hiding the invitation information image 54 are not limited to these. In any case, it is sufficient that the invitation information image 54 is hidden based on the input of a predetermined operation that includes at least the joining operation.

[0267] Furthermore, in the above embodiment, invitation information of the same battle game type as the invitation information stored in the state storage unit may not be received. In other words, the player terminal 1 can hold multiple pieces of invitation information, but the invitation information that can be held simultaneously may be limited to pieces of invitation game with different types. Furthermore, if the invitation information that can be held simultaneously in the player terminal 1 is limited to pieces of invitation game with different types, the thumbnail image 52a and the invitation information image 54 may be hidden after all of the invitation information is received.

[0268] In this way, when the invitation information that can be held simultaneously is limited to invitation games of different types, the invitation games corresponding to the plurality of notification images will be of different types.

[0269] Furthermore, in the above embodiment, for example, if multiple pieces of invitation information with the same type of invitation game are held, only the thumbnail image 52a corresponding to any one of the multiple pieces of invitation information may be displayed. In this way, when multiple notification images are displayed, the invitation games corresponding to the multiple notification images will be of different types. This prevents only the same type of invitation game from being displayed, thereby broadening the range of choices available to the player.

[0270] In the above-described embodiments and various modified examples, an information processing system S, which is a client-server system, performs the above-described information processing. However, only the player terminal 1 in the above-described embodiments and modified examples 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. Furthermore, only the server 100 in the above-described embodiments and modified examples may be provided as a server device.

[0271] The programs in the above embodiments and various modifications may be stored in a computer-readable storage medium and provided as such. Furthermore, they may be provided as a game terminal device or server device that includes such a storage medium. Furthermore, the above embodiments and modifications may be information processing methods that implement the functions and steps shown in the flowcharts. [Explanation of symbols]

[0272] 1. Player terminal 52a Thumbnail image 54 Invitation information image 54a Game information display section 54b Operation section 60a Game Execution Unit 62a Battle Game Execution Department 68a Invitation Information Receiving Section 70a Notification Department 72a Invitation information image display section 74a Processing section 100 servers

Claims

1. a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; a process of interrupting the predetermined game being played when a player's operation of selecting the notification image or the specific image is input; a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select the notification image or the specific image; a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; The computer executes the following: The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; The notification image can be displayed in the notification mode even after a predetermined time has elapsed since the start of display of the specific image and the specific image has become invisible. Information processing program.

2. The notification image is One invitation is displayed regardless of the number of invitations received. The information processing program according to claim 1 .

3. a process of resuming the predetermined game when a predetermined operation is input while the predetermined game is suspended; The computer executes the following: The notification image is The notification is displayed in the same manner even after the predetermined game is restarted.

3. The information processing program according to claim 1.

4. the notification image is displayed on a game screen other than the predetermined game at the same position as when the predetermined game is being played; 3. The information processing program according to claim 1.

5. An information processing method performed by a computer, comprising: The computer a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; a process of interrupting the predetermined game being played when a player's operation of selecting the notification image or the specific image is input; a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select the notification image or the specific image; a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; and The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; The notification image can be displayed in the notification mode even after a predetermined time has elapsed since the start of display of the specific image and the specific image has become invisible. Information processing methods.

6. An information processing system in which a player terminal and an external device are communicatively connected, The player terminal a process of displaying a game screen of a predetermined game during play of the predetermined game requiring a player's operation; receiving, from an external device, invitation information inviting the player to participate in one of a plurality of types of invitation games; a process of displaying a notification image in a notification manner that notifies a player that the invitation information has been received while the player is playing the predetermined game, while maintaining the display of the game screen of the predetermined game being played; and a process of displaying a specific image that can identify the type of the inviting game at least while the notification image is being displayed in the notification mode when the invitation information is received; a process of hiding the specific image when a predetermined time has elapsed since the start of displaying the specific image; a process of interrupting the predetermined game being played when a player's operation of selecting the notification image or the specific image is input; a process of displaying, while the predetermined game is suspended, game information regarding the inviting game and a predetermined image including at least an operation unit for accepting an operation to participate in the inviting game, based on an input of a player's operation to select the notification image or the specific image; a process of executing a process for participating in the invitation game when the participation operation is input to the operation unit; and The process of displaying the predetermined image includes: When a plurality of pieces of invitation information are received, the predetermined image is displayed so that the participation operation for any one of the plurality of invitation games can be input; displaying the predetermined image in common when a player's operation to select the notification image is input and when a player's operation to select the specific image is input; The notification image can be displayed in the notification mode even after a predetermined time has elapsed since the start of display of the specific image and the specific image has become invisible. Information processing system.

Images