Information processing program, game terminal device, and information processing system

Abstract

The information processing program according to the present invention causes a computer to function as: a request information sending unit (64a) that sends request information to an external device in response to an input of a request operation from an operation unit; a game state updating unit (66a) that updates a game state at least based on a game playing situation; an invitation information receiving unit (68a) that can receive invitation information from the external device when the game state is a permission state; an invitation information reporting unit (70a) that reports the reception of the invitation information when the invitation information is received or after the invitation information is received; an operation permission unit (72a) that enables a specified participation operation to be input when the reception of the invitation information is reported or after the reception of the invitation information is reported; and a game execution unit (60a) that executes a communication game with other player terminals when the participation operation is input and a specified start condition is satisfied.

Description

Technical Field

[0001] The present invention relates to an information processing program, a game terminal device, and an information processing system. Background Art

[0002] Communication games (hereinafter referred to as multiplayer games) in which multiple players can participate are conventionally known. In a multiplayer game, it is necessary to match players who wish to participate in the game. For example, Patent Document 1 proposes a game system that accepts an application for a battle from another player (a subsequent player) when a prior player is playing a game.

[0003] According to this game system, an image indicating an application for a battle is displayed on the game screen of the prior player. Then, when the prior player performs an operation for accepting the application, the multiplayer game starts after waiting for the game being played by the prior player to end.

[0004] Prior Art Documents

[0005] Patent Documents

[0006] Patent Document 1: Japanese Patent Application Laid-Open No. 2000-140413 Summary of the Invention

[0007] Problems to be Solved by the Invention

[0008] With the above-described game system, the multiplayer game cannot start until the prior player finishes playing the game being played. Thus, there is a case where it takes a long time to start the multiplayer game depending on the game situation of the prior player.

[0009] An object of the present invention is to provide an information processing program, a game terminal device, and an information processing system that can shorten the time required to start a communication game in which multiple players can participate.

[0010] Means for Solving the Problems

[0011] To solve the above problems, an information processing program according to the present invention causes a computer to function as: a request information sending unit that sends request information to an external device in response to an input of a request operation from an operation unit; a state updating unit that updates a game state based at least on a game playing situation; a receiving unit that can receive invitation information from the external device when the game state is a permission state; a reporting unit that reports the reception of the invitation information when the invitation information is received or after the invitation information is received; an operation permission unit that enables a specified participation operation to be input when the reception of the invitation information is reported or after the reception of the invitation information is reported; and a game execution unit that executes a communication game with another player terminal when the participation operation is input and a specified start condition is satisfied.

[0012] To solve the above problems, an information processing program according to the present invention is used to make a computer function as: a request information sending unit that sends request information to an external device in response to an input of a request operation from an operation unit; a state updating unit that updates a game state at least based on a game playing situation; a receiving unit that can receive invitation information from the external device; a reporting unit that reports the reception of the invitation information when or after the invitation information is received when the game state is a permission state; an operation permission unit that enables a specified participation operation to be input when or after the reception of the invitation information is reported; and a game execution unit that executes a communication game with other player terminals when the participation operation is input and a specified start condition is satisfied.

[0013] In addition, after the termination of the communication game, the state updating unit can set the game state to an impossible state where the reception of the invitation information or the reporting of the reception of the invitation information cannot be performed during a first time period.

[0014] In addition, the operation permission unit can enable a rejection operation for rejecting participation in the communication game to be input when or after the reception of the invitation information is reported, and the state updating unit can set the game state to an impossible state where the reception of the invitation information or the reporting of the reception of the invitation information cannot be performed during a second time period after the rejection operation is input.

[0015] In addition, the operation permission unit can enable a specified suspension operation to be input when or after the reception of the invitation information is reported, and the reporting unit can continue the reporting when the suspension operation is input and terminate the reporting when non-participation information that can be received when unable to participate in the communication game is received.

[0016] To solve the above problems, a game terminal device can be provided, which includes a storage medium storing the above information processing program.

[0017] In order to solve the above problems, an information processing system according to the present invention includes: an accumulation unit configured to accumulate prescribed player information for each player in a storage unit; a state update unit configured to update a game state based at least on a game-playing situation at a player terminal; a request information sending unit configured to send request information in response to an input of a request operation on an operation unit of the player terminal; a setting unit configured to, when the request information is received from the player terminal, set a plurality of player terminals as extraction terminals capable of receiving invitation information based at least on the player information accumulated in the storage unit; a receiving unit capable of receiving the invitation information at each extraction terminal in a case where the game state is a permission state; a reporting unit configured to report reception of the invitation information when the invitation information is received or after the invitation information is received; an operation permission unit configured to enable input of a prescribed participation operation when the reception of the invitation information is reported or after the reception of the invitation information is reported; and a game execution unit configured to execute a communication game between one or more extraction terminals that have sent participation information based on the input of the participation operation and the player terminal that has sent the request information.

[0018] In order to solve the above problems, an information processing system according to the present invention includes: an accumulation unit configured to accumulate prescribed player information for each player in a storage unit; a state update unit configured to update a game state based at least on a game-playing situation at a player terminal; a request information sending unit configured to send request information in response to an input of a request operation on an operation unit of the player terminal; a setting unit configured to, when the request information is received from the player terminal, set a plurality of player terminals as extraction terminals capable of receiving invitation information based at least on the player information accumulated in the storage unit; a receiving unit capable of receiving the invitation information at each extraction terminal; a reporting unit configured to report reception of the invitation information at each extraction terminal when the game state is a permission state, when the invitation information is received or after the invitation information is received; an operation permission unit configured to enable input of a prescribed participation operation when the reception of the invitation information is reported or after the reception of the invitation information is reported; and a game execution unit configured to execute a communication game between one or more extraction terminals that have sent participation information based on the input of the participation operation and the player terminal that has sent the request information.

[0019] Effects of the Invention

[0020] The present invention enables shortening of the time required to start a communication game in which a plurality of players can participate. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is an explanatory diagram showing a schematic configuration of the information processing system.

[0022] Figure 2A It is a diagram for explaining the hardware structure of the player terminal.

[0023] Figure 2B It is a diagram for explaining the hardware structure of the server.

[0024] Figure 3A It is a diagram showing an example of the party organization screen.

[0025] Figure 3B It is a diagram for explaining an example of the information confirmation screen.

[0026] Figure 3C It is a diagram for explaining an example of the combat game selection page in the mission screen.

[0027] Figure 3D It is a diagram for explaining an example of the game content selection page in the mission screen.

[0028] Figure 4A It is a diagram for explaining an example of the game content selection page when single-player game is selected.

[0029] Figure 4B It is a diagram for explaining an example of the combat screen.

[0030] Figure 4C It is a diagram for explaining an example of the result screen.

[0031] Figure 5A It is a diagram for explaining an example of the game content selection page when multiplayer game is selected.

[0032] Figure 5B It is a diagram for explaining an example of the room selection page.

[0033] Figure 5C It is a diagram for explaining an example of the object selection page.

[0034] Figure 5D It is a diagram for explaining an example of the room details page.

[0035] Figure 6A It is a diagram for explaining an example of the report of receiving invitation information in the normal screen.

[0036] Figure 6B It is a diagram for explaining an example of the report of receiving invitation information in the combat screen.

[0037] Figure 6C It is a diagram for explaining an example of the invitation information dialog box.

[0038] Figure 6DIt is a diagram showing an example of the screen after the shelving operation.

[0039] Figure 7A It is a diagram showing an example of the screen before the rejection operation.

[0040] Figure 7B It is a diagram showing an example of the screen after the rejection operation.

[0041] Figure 7C It is a diagram showing an example of the screen before the participation operation.

[0042] Figure 7D It is a diagram showing an example of the screen after the participation operation.

[0043] Figure 8A It is a diagram showing an example of the report mode for receiving guidance information in the normal screen.

[0044] Figure 8B It is a diagram showing an example of the guidance information dialog box.

[0045] Figure 8C It is a diagram showing an example of the screen after the non-display operation.

[0046] Figure 8D It is a diagram showing an example of the screen after the viewing operation.

[0047] Figure 9A It is a diagram showing the priority points.

[0048] Figure 9B It is a diagram showing the priority point update conditions.

[0049] Figure 10 It is the first diagram showing the list update process.

[0050] Figure 11 It is the second diagram showing the list update process.

[0051] Figure 12 It is the third diagram showing the list update process.

[0052] Figure 13 It is the fourth diagram showing the list update process.

[0053] Figure 14A It is a diagram showing the game state of the player terminal.

[0054] Figure 14B It is a diagram showing the timing of receiving confirmation of the invitation information.

[0055] Figure 15 It is a sequence diagram showing the basic processing of the player terminal and the server.

[0056] Figure 16 It is a sequence diagram for explaining the processing of the player terminal and the server in the case of executing a multiplayer game.

[0057] Figure 17 It is a sequence diagram for explaining the processing of the player terminal and the server in the case of being unable to participate in a multiplayer game.

[0058] Figure 18 It is a sequence diagram for explaining the processing of the player terminal and the server in the case of refusing to participate in a multiplayer game.

[0059] Figure 19 It is a diagram for explaining the structure of the memory of the player terminal and the functions of the player terminal in the form of a computer.

[0060] Figure 20 It is a flowchart for explaining an example of the terminal-side game processing of the player terminal.

[0061] Figure 21 It is a flowchart for explaining an example of the processing related to room creation at the player terminal.

[0062] Figure 22 It is a flowchart for explaining an example of the invitation information reception processing at the player terminal.

[0063] Figure 23 It is a flowchart for explaining an example of the invitation information confirmation processing at the player terminal.

[0064] Figure 24 It is the first flowchart for explaining an example of the post-processing after receiving the invitation information at the player terminal.

[0065] Figure 25 It is the second flowchart for explaining an example of the post-processing after receiving the invitation information at the player terminal.

[0066] Figure 26 It is a flowchart for explaining an example of the multiplayer game termination processing at the player terminal.

[0067] Figure 27 It is a diagram for explaining the structure of the memory of the server and the functions of the server as a computer.

[0068] Figure 28 It is a flowchart for explaining an example of the server-side game processing at the server.

[0069] Figure 29 It is a flowchart for explaining an example of the request information reception processing at the server.

[0070] Figure 30It is a flowchart for illustrating an example of information update processing at a server.

[0071] Figure 31 It is a flowchart for illustrating an example of multiplayer game termination processing at a server.

[0072] Figure 32 It is a flowchart for illustrating an example of reordering processing at a server.

[0073] Figure 33 It is a flowchart for illustrating an example of invitation information reception processing at a player terminal in a modification.

[0074] Figure 34 It is a diagram for illustrating the structure of the memory of a player terminal and the functions of the player terminal as a computer in a second embodiment.

[0075] Figure 35 It is a diagram for illustrating the structure of the memory of a server and the functions of the server as a computer in a second embodiment.

[0076] Figure 36A It is a first sequence diagram for illustrating the processing of a player terminal and a server in a second embodiment.

[0077] Figure 36B It is a second sequence diagram for illustrating the processing of a player terminal and a server in a second embodiment.

[0078] Figure 36C It is a third sequence diagram for illustrating the processing of a player terminal and a server in a second embodiment. Specific Embodiments

[0079] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The dimensions, materials, other specific numerical values, etc. given in such embodiments are merely examples for facilitating the understanding of the embodiments, and do not limit the present invention unless otherwise specifically mentioned. In this specification and the drawings, elements having substantially the same functions and structures are attached with the same reference numerals and are not repeatedly described, and elements not directly related to the present invention are not shown.

[0080] (Overall Structure of Information Processing System S)

[0081] Figure 1 It is an explanatory diagram showing the schematic structure of the information processing system S. The information processing system S is a so-called client - server system including a player terminal 1, a server 100, and a communication network 200 having a communication base station 200a.

[0082] The player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 includes various electronic devices that can establish a wired or wireless connection with the server 100 for communication. The player terminal 1 includes, for example, a smart phone, a mobile phone, a tablet device, a personal computer, a game device, etc. In this embodiment, the case where a smart phone is used as the player terminal 1 will be described.

[0083] The server 100 is connected to a plurality of player terminals 1 for communication. The server 100 accumulates various information (player information) for each player who plays the game. In addition, based on the operations input from the player terminal 1, the server 100 updates the accumulated information and controls the progress of the game.

[0084] The communication base station 200a is connected to the communication network 200 and performs wireless transmission and reception of information with respect to the player terminal 1. The communication network 200 is implemented by a mobile phone network, the Internet, a LAN (local area network), or a dedicated line, etc., and realizes the wired or wireless connection used for communication between the player terminal 1 and the server 100.

[0085] In the information processing system S according to this embodiment, the player terminal 1 and the server 100 are used as game devices G. The player terminal 1 and the server 100 share roles related to the progress control of the game, and the cooperation between the player terminal 1 and the server 100 enables the game to continue.

[0086] (Hardware structures of the player terminal 1 and the server 100)

[0087] Figure 2A is a diagram for explaining the hardware structure of the player terminal 1. In addition, Figure 2B is a diagram for explaining the hardware structure of the server 100. As Figure 2A shown, the player terminal 1 is configured to include 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.

[0088] In addition, as Figure 2B shown, the server 100 is configured to include 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.

[0089] Note that the structures 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 24 of the server 100 are basically 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 hardware structure of the player terminal 1 will be described below, and the description of the hardware structure of the server 100 will be omitted.

[0090] The CPU 10 runs the programs stored in the memory 12 and controls the progress of the game. The memory 12 is implemented by a ROM (Read-Only Memory) or a RAM (Random Access Memory), and stores the programs and various data required for controlling the progress of the game. The memory 12 is connected to the CPU 10 via the bus 14.

[0091] The input / output interface 16 is connected to the bus 14. The storage unit 18, communication unit 20, input unit 22, and output unit 24 are connected to the input / output interface 16.

[0092] The storage unit 18 is implemented by a semiconductor memory such as a DRAM (Dynamic Random Access Memory), and stores various programs and data. At the player terminal 1, the CPU 10 loads the programs and data stored in the storage unit 18 into the memory 12 (RAM).

[0093] 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. At 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.

[0094] The input unit 22 is implemented, for example, by a touch panel through which a player operation is input (through which a player operation passes), buttons, a keyboard, a mouse, a cross key, or an analog controller. In addition, the input unit 22 can be a dedicated controller provided in the player terminal 1 or connected (externally attached) to the player terminal 1. In addition, the input unit 22 can be implemented by an acceleration sensor that detects the tilt or movement of the player terminal 1 or a microphone that detects the player's voice. That is, the input unit 22 includes various devices capable of inputting the player's intention in a recognizable manner.

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

[0096] (Game content)

[0097] Next, the content of the game provided by the information processing system S (game device G) according to the present embodiment will be described by using examples. In the present embodiment, a so-called battle game in which ally characters battle against enemy characters is provided. Specifically, in the game of the present embodiment, a plurality of ally characters are provided. The player organizes a team by selecting a plurality of ally characters (in this case, three) from the provided ally characters. In addition, the player can play a plurality of types of battle games with different enemy characters or difficulty levels. The purpose of the battle game is for the player to operate the ally characters organized into a team and defeat the enemy characters to obtain rewards.

[0098] Figure 3A is a diagram showing an example of a team organization screen. Figure 3B is a diagram for explaining an example of an information confirmation screen. Figure 3C is a diagram for explaining an example of a battle game selection page in the mission screen. Figure 3D is a diagram for explaining an example of a game content selection page in the mission screen. It is displayed on the display 26 of the player terminal 1 Figure 3A , Figure 3B , Figure 3C and Figure 3D the game screens shown. In the present embodiment, the game screens are roughly classified into a normal screen and a battle screen.

[0099] The normal screen is mainly a screen for the player to make various settings or confirm information. On the other hand, the battle screen is a screen displayed on the display 26 from the start to the end of the battle game. Here, all screens other than the battle screen are normal screens. The normal screen is roughly classified into four screens, namely, a main screen (not shown), Figure 3A the team organization screen shown in Figure 3B , the information confirmation screen shown in Figure 3C and Figure 3D the mission screen shown in.

[0100] Note that the team organization screen and the mission screen are composed of multiple pages, and these pages are switched by player operations. In the normal screen, a header display area 30 is provided at the upper part of the display 26. An endurance display bar 32 indicating the player's endurance is displayed in the header display area 30.

[0101] Note that endurance is a parameter required to play combat games. In this embodiment, multiple types of combat games are provided, and for each combat game, an endurance consumption value required to play the combat game is set. Since a player plays a combat game by consuming endurance, the player cannot play the combat game when the player does not have enough endurance.

[0102] Although detailed description will be omitted, when a player wins a combat game, the player can obtain a specified value as the player experience value. In addition, whenever the player experience value reaches a certain value, the player level is increased. An endurance upper limit value is set for the player level, and as the player level increases, the endurance upper limit value becomes higher. Endurance is restored by a specified value (for example, 1 point) at regular time intervals (for example, 5 minutes) within the range up to the upper limit value. The endurance display bar 32 is displayed in such a way that the current remaining endurance amount relative to the endurance upper limit value can be visually grasped.

[0103] In addition, a notification image 34 is displayed at the left end of the header display area 30. Although details will be described later, the notification image 34 reports to the player the reception of combat game invitation information or event guidance information. In a state where no invitation information or guidance information is received, the notification image 34 is displayed in a non-reporting mode. Note that the notification image 34 in the non-reporting mode is displayed in a light color. On the other hand, in a state where at least one of the invitation information and the guidance information is received, the notification image 34 is displayed in a reporting mode. The notification image 34 in the reporting mode is highlighted in a color that is more conspicuous than the notification image 34 in the non-reporting mode.

[0104] In addition, in the normal screen, a menu bar 36 is displayed at the lower part of the display 26. In the menu bar 36, multiple operation parts that can be operated (tapped) by the player are provided. Here, as an example of the operation part, a main screen selection part 36a shown as "Home", a team organization screen selection part 36b shown as "Team", a task screen selection part 36c shown as "Task", and an information confirmation screen selection part 36d shown as "Information" are provided in the menu bar 36.

[0105] When the main screen selection part 36a is tapped, the main screen is displayed on the display 26. In addition, when the team organization screen selection part 36b is tapped, Figure 3A the team organization screen shown is displayed on the display 26. Similarly, when the information confirmation screen selection part 36d is tapped, Figure 3B the information confirmation screen shown is displayed on the display 26, and when the task screen selection part 36c is tapped, Figure 3C the task screen (combat game selection page) shown is displayed on the display 26.

[0106] As described above, the normal screens are roughly classified into four screens. In the menu bar 36, the operation parts corresponding to the respective screens are highlighted so that the screens displayed on the display 26 can be recognized. Note that when the page changes in the normal screen or when the normal screen changes to a different normal screen, the stamina display bar 32, the notification image 34, and the menu bar 36 are still displayed. That is, when a change occurs in the normal screen, the images other than the header display area 30 and the menu bar 36 are switched.

[0107] In the Figure 3A team organization screen shown as above, all ally characters owned by the player are displayed. The player can organize a team by selecting three ally characters from the displayed ally characters. Here, up to six teams can be organized and stored. Experience values and levels are stored in association with the respective ally characters. When the player wins the battle game described later or when a prescribed item is used, the experience value increases. The level is set according to the experience value, and the level is raised whenever the experience value reaches a prescribed value. Note that a level upper limit value is set for each ally character, and the level is raised within the range up to the upper limit value.

[0108] In addition, combat power base values such as hit points, attack power, and defense power are set for the ally characters according to the levels of the ally characters. When the combat power of the ally characters becomes higher, the player can advantageously continue the battle game. In addition, each of the base values set for the ally characters increases as the level becomes higher.

[0109] In addition, in the team organization screen, the player can equip the ally characters included in the team with equipment such as weapons and armor (equipment is set for the ally characters). Values to be added to the attack power, defense power, etc. are set for each piece of equipment. When an ally wears the equipment, the value to be added for the equipment is added to the above base value, thereby making it possible to increase the combat power of the ally.

[0110] In the Figure 3B information confirmation screen shown as above, player information related to the player is displayed. As the player information, for example, the player name, player experience value, player level, player ranking, the number of owned characters (the number of ally characters the player has), the number of followers, and the number of mutual followers are displayed. Note that in the present embodiment, a follower refers to another player set by the player as a so-called favorite or comrade-in-arms. In addition, in the present embodiment, mutual followers refer to players who have mutually set each other as followers.

[0111] Figure 3COn the battle game selection page of the task screen shown, the types of battle games being offered are displayed, that is, multiple selection tabs 38 with the names of the battle games are shown. Here, ten types of battle games are provided, and ten selection tabs 38 are displayed. Note that opening conditions are set for each battle game. The opening conditions include, for example, conditions where the player's experience value, player level, and player ranking are greater than or equal to a specified value, and conditions where other specified battle games have been cleared.

[0112] Players can play battle games that meet the opening conditions. Therefore, on the battle game selection page, as shown in the figure, a lock is displayed on the selection tab 38 of the battle game that does not meet the opening conditions. In addition, only the selection tab 38 of the battle game that meets the opening conditions accepts player operations (taps).

[0113] On the battle game selection page, when a selection tab 38 is tapped, the Figure 3D game content selection page shown is displayed. On this game content selection page, a team to be used in the battle game can be selected from the teams organized in the team organization screen. In addition, this embodiment provides a single-player game where a player plays the battle game alone and a multiplayer game where a player plays the battle game by performing communication with other players as the types of games. On the game content selection page, a single-player game tab 40a and a multiplayer game tab 40b are displayed.

[0114] Figure 4A is a diagram for explaining an example of the game content selection page when the single-player game is selected. Figure 4B is a diagram for explaining an example of the battle screen. Figure 4C is a diagram for explaining an example of the result screen. As Figure 4A shown, when the single-player game tab 40a is operated in a state where the type of battle game and the team to be used in the battle game have been selected, the single-player game starts. Note that the ally characters included in the team to be used in the battle game, that is, the ally characters that the player is to operate in the battle game will hereinafter be referred to as "player characters". In the battle game, the player operates the input unit 22 of the player terminal 1 to operate the player character.

[0115] During the battle game, as shown in Figure 4B, the battle screen is displayed. In the battle screen, the player character and the enemy character are displayed on the display 26. The player character is operated according to the player's operation, causing damage to the enemy character or being damaged by the enemy character. In addition, the enemy character is operated by computer control, causing damage to the player character or being damaged by the player character.

[0116] When damage points are assigned to an enemy character, these damage points are subtracted from the enemy character's hit points. Similarly, when damage points are assigned to a player character, these damage points are subtracted from the player character's hit points. When the enemy character's hit points reach zero, the player wins the battle game, and when all player characters' hit points reach zero, the player loses the battle game.

[0117] Here, in the battle screen, as Figure 4B shown, the menu bar 36 that is displayed in the normal screen is hidden. Further, in the header display area 30, the stamina display bar 32 is hidden, and the hit points of each player character are displayed. Further, in the battle screen, an operation tab 42 is displayed in the header display area 30. The display position of the operation tab 42 is the same as the position in the header display area 30 where at least a part of the notification image 34 is displayed in the normal screen.

[0118] When the operation tab 42 is tapped during the battle game, the battle game is put on hold. At this time, on the display 26, a hold screen (not shown) is displayed on the battle screen in a superimposed manner. An exit operation section and a resume operation section are provided in the hold screen, and the player can select to exit the battle game (terminate the battle game) or resume the battle game by tapping these operation sections.

[0119] When the battle game is normally terminated (normally ended), as Figure 4C shown, a result screen is displayed on the display 26. In the present embodiment, the normal termination of the battle game includes three termination modes, namely, an intermediate termination due to exit, a win termination in which victory is confirmed during the battle game, and a loss termination in which defeat is confirmed during the battle game. Although Figure 4C the result screen at the time of win termination is shown as an example, the result screen is different for each termination mode.

[0120] The result screen displays a termination operation section 44 shown as "closed", and when this termination operation section 44 is tapped, the display of the display 26 switches from the battle screen to the normal screen. That is, the result screen is a part of the battle screen. Note that the normal screen to which the result screen switches may be the screen that was displayed immediately before switching to the battle screen, or may be a prescribed screen such as the main screen. In this way, when the display of the result screen ends, the battle game ends.

[0121] Figure 5A is a diagram for explaining an example of a game content selection page when a multiplayer game is selected. Figure 5B is a diagram for explaining an example of a room selection page. Figure 5C is a diagram for explaining an example of a person selection page. Figure 5D is a diagram for explaining an example of a room details page. AsFigure 5A As shown, it is assumed that the multiplayer game tab 40b is tapped in a state where the type of battle game is selected and the team to be used in the battle game is selected.

[0122] In this case, as Figure 5B shown, a room selection page of the mission screen is displayed. On the room selection page, a room creation tab 46 shown as "Create Room" is displayed. In the present embodiment, a "room" refers to a place where all players participating in a multiplayer game share information, or sometimes refers to an area secured at the server 100 for performing a multiplayer game.

[0123] When a player performs a multiplayer game, the player can create a room by tapping the room creation tab 46 (inputting a request operation). Note that a player who creates a room in a multiplayer game will be hereinafter referred to as a host player. In addition, a player who enters a room created by another player will be referred to as a guest player.

[0124] When the room creation tab 46 is tapped, as Figure 5C shown, a person selection page of the mission screen is displayed. On the person selection page, a follower tab 48a shown as "Follower", a mutual follower tab 48b shown as "Mutual Follower", and a random tab 48c shown as "Random" are displayed. On the person selection page, the player who creates the room can select the person (guest player) to be invited to the room he / she creates.

[0125] Specifically, when the follower tab 48a is operated, the player set as a follower by the player who creates the room is set as the person who can receive invitation information. Note that in the present embodiment, only the player set as the person can receive invitation information, and a player who is not set as the person cannot receive invitation information. In addition, as will be described in detail later, unless a certain condition is satisfied, the person cannot receive invitation information. Thus, a person is merely a player who has the right to receive invitation information.

[0126] When the mutual follower tab 48b is operated, the player set as a mutual follower by the player who creates the room is set as the person. On the other hand, when the random tab 48c is operated, a person is set from all the players registered in the server 100. When the player terminal 1 of the player set as the person performs communication with the server 100, the player receives invitation information. The person who receives the invitation information can decide whether to enter the room, that is, whether to participate in the multiplayer game. Thus, entering the room is limited to the players who receive the invitation information.

[0127] For example, as Figure 5C shown, when the random tab 48c is tapped, as Figure 5DAs shown, a room details information page that displays a task screen. On the room details information page, various information (room information) including team information indicating the team selected by the host player is displayed. In addition, on the host player's room details page, a start tab 50 shown as "Ready" is displayed. When the host player taps the start tab 50, a multiplayer game starts.

[0128] Figure 6A It is a diagram for explaining an example of a report on receiving invitation information in a normal screen. Figure 6B It is a diagram for explaining an example of a report on receiving invitation information in a battle screen. Figure 6C It is a diagram for explaining an example of an invitation information dialog box 52. Figure 6D It is a diagram for explaining an example of the screen after a shelving operation. For example, assume as Figure 6A shown, at the player terminal 1 of the target person, an information confirmation screen is displayed on the display 26. In this state, when the player terminal 1 receives invitation information, as shown in the figure, in the header display area 30, the notification image 34 switches from the non-report mode to the report mode.

[0129] In addition, assume as Figure 6B shown, at the player terminal 1 of the target person, a battle screen is displayed on the display 26. As described above, in the battle screen, the operation tab 42 is usually displayed in the header display area 30 (see Figure 4B ), but when the player terminal 1 receives invitation information, as shown in the figure, the operation tab 42 switches to the notification image 34 in the report mode.

[0130] When the notification image 34 displayed in the report mode is tapped, as Figure 6C shown, the invitation information dialog box 52 is displayed (opened). The invitation information dialog box 52 is displayed in a superimposed manner on the screen displayed when the notification image 34 is tapped. In addition, in the case of tapping the notification image 34 during a battle game, similar to the case of tapping the operation tab 42, the battle game is shelved, and the invitation information dialog box 52 is displayed in a superimposed manner on the battle screen displayed when shelved.

[0131] In the invitation information dialog box 52, for example, information such as the player rank or player name of a player such as the host player or the type of battle game to be played in the multiplayer game is displayed as task information. In addition, in the invitation information dialog box 52, a participation tab 52a shown as "Yes", a rejection tab 52b shown as "No", and a shelving tab 52c shown as "Close" are provided.

[0132] The participation tab 52a accepts a participation operation for applying to participate in a multiplayer game, that is, for entering the room to which the target person has been invited. In addition, the rejection tab 52b accepts a rejection operation for rejecting participation in the multiplayer game. In addition, the hold tab 52c accepts a hold operation for holding the decision on whether to participate in the multiplayer game.

[0133] For example, assume that after the invitation information dialog 52 is opened, the hold tab 52c is tapped to input a hold operation. When the hold operation is input, as Figure 6D shown, the invitation information dialog 52 is closed (hidden). However, in the case where the hold operation is input, the notification image 34 continues to be displayed in the reporting mode. Note that when the hold operation is input during a battle game while the invitation information dialog 52 is being displayed, the battle game is continued while the invitation information dialog 52 is closed. Also in this case, the notification image 34 continues to be displayed in the reporting mode.

[0134] Figure 7A It is a diagram showing an example of the screen before the rejection operation. Figure 7B It is a diagram showing an example of the screen after the rejection operation. As Figure 7A shown, assume that after the invitation information dialog 52 is opened, the rejection tab 52b is tapped to input a rejection operation. When the rejection operation is input, as Figure 7B shown, while the invitation information dialog 52 is closed (hidden), the notification image 34 switches to the non-reporting mode.

[0135] Note that in the case where the rejection operation is input during a battle game while the invitation information dialog 52 is being displayed, the battle game is continued while the invitation information dialog 52 is closed. In this case, in the header display area 30, the notification image 34 is hidden and the operation tab 42 is displayed.

[0136] Figure 7C It is a diagram showing an example of the screen before the participation operation. Figure 7D It is a diagram showing an example of the screen after the participation operation. As Figure 7C shown, assume that after the invitation information dialog 52 is opened, the participation tab 52a is tapped to input a participation operation. When the participation operation is input, participation information is sent from the player terminal 1 of the target person to the server 100. When the participation information is input, the server 100 determines whether it is possible to enter the room to which the target person has been invited.

[0137] Specifically, regarding the room to which the subject is invited, it is determined that entry into the room is not possible when the multiplayer game has already started (during game progress), when the number of guest players present in the room reaches the upper limit number (full capacity), or when the room no longer exists (is disbanded). In such a case, a dialog box (room entry not possible screen) not shown in the figure indicating that entry into the room is not possible is displayed on the display 26 of the player terminal 1.

[0138] On the other hand, it is assumed that the server 100 determines that entry into the room is possible. In such a case, the player information of the subject who has sent the participation information is added to the room, and the room information is updated. Thus, when the subject successfully enters the room by performing the participation operation, the subject is set as a guest player. In addition, when the room information is updated, the host player and all guest players receive the updated room information.

[0139] At this time, as Figure 7D shown, a room details page 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. Note that, as described above, a start tab 50 is provided on the room details page displayed on the player terminal 1 of the host player (hereinafter referred to as the "host terminal"). On the other hand, as Figure 7D shown, the start tab 50 is not provided on the room details page displayed on the guest terminal. Therefore, only the host player can start the multiplayer game.

[0140] Note that an operation unit for accepting an operation to leave the room is not provided on the room details page displayed on the guest terminal. That is, guest players cannot officially leave the room they have entered. This suppresses the situation where guest players repeatedly enter and leave the room, and enables the early start of the multiplayer game. However, an operation unit for leaving the room can be provided on the room details page of the guest terminal so that guest players can leave the room. In addition, an operation unit for intentionally disbanding the room can be provided on the room details page displayed on the host terminal.

[0141] Note that although not shown, when the notification image 34 displayed in the non-report mode is tapped, a dialog box reporting the absence of invitation information is displayed. As described above, when the rejection operation is performed, the notification image 34 switches to the non-report mode. Therefore, even if the notification image 34 is operated immediately after the rejection operation is input, the absence of invitation information is reported. That is, once the subject rejects participation in the multiplayer game, the subject can no longer participate in the multiplayer game.

[0142] On the other hand, in the case of performing the above-described shelving operation, even after the invitation information dialog box 52 is closed, the notification image 34 is displayed in the report mode. Therefore, when the notification image 34 is tapped again after the shelving operation, the invitation information dialog box 52 is displayed again, enabling the subject person to input a participation operation for the multiplayer game to which the subject person is invited. However, as described above, in the case where the room to which the subject person is invited is in the state of "in-game", "full", or "dissolved", it is determined that the subject person cannot enter the room, and a dialog box indicating that the subject person cannot enter the room is displayed.

[0143] Figure 8A It is a diagram for explaining an example of the report mode for receiving guidance information in the normal screen. Figure 8B It is a diagram for explaining an example of the guidance information dialog box 54. Figure 8C It is a diagram for explaining an example of the screen after the non-display operation. Figure 8D It is a diagram for explaining an example of the screen after the viewing operation. In the present embodiment, the player terminal 1 receives the guidance information of the event. The guidance information is set by the administrator in the server 100, and when the player terminal 1 performs communication with the server 100, the player terminal 1 receives the guidance information from the server 100.

[0144] Similar to the reception of the invitation information, the reception of the guidance information is reported to the player through the notification image 34. For example, as Figure 8A shown, when the guidance information is received in the state where the information confirmation screen is displayed on the display 26, the notification image 34 switches to the report mode. When the notification image 34 is tapped in this state, as Figure 8B shown, the guidance information dialog box 54 is displayed (opened). The guidance information dialog box 54 is displayed in an overlay manner on the screen that is being displayed when the notification image 34 is tapped. In addition, in the case where the notification image 34 is tapped during the battle game, the battle game is shelved, and the guidance information dialog box 54 is displayed in an overlay manner on the battle screen that is being displayed when shelved.

[0145] In the guidance information dialog box 54, for example, information related to the tasks regularly maintained is displayed. In addition, in the guidance information dialog box 54, a non-display tab 54a shown as "Close" and a viewing tab 54b shown as "To Event" are provided. The non-display tab 54a accepts a non-display operation for terminating the display of the guidance information dialog box 54. In addition, the viewing tab 54b accepts a viewing operation for viewing the event information.

[0146] For example, it is assumed that after the guidance information dialog box 54 is opened, the non-display tab 54a is tapped to input a non-display operation. When the non-display operation is input, as Figure 8CAs shown, the guidance information dialog box 54 is closed (hidden). However, in the case of an input of a non-display operation, the notification image 34 continues to be displayed in the reporting mode. Note that when a non-display operation is input during a battle game while the guidance information dialog box 54 is being displayed, the battle game is continued while closing the guidance information dialog box 54. Also in this case, the notification image 34 continues to be displayed in the reporting mode. However, in the case of an input of a non-display operation from the non-display tab 54a, the notification image 34 can be switched from the reporting mode to the non-reporting mode.

[0147] On the other hand, it is assumed that after the guidance information dialog box 54 is opened, the view tab 54b is tapped to input a view operation. When the view operation is input, as Figure 8D shown, an event guidance screen showing information related to an event in which the player can participate is displayed. Although detailed description will be omitted, the player can input an operation on the event guidance screen, and the input operation enables participation in the event. Note that when the event guidance screen is displayed, the notification image 34 is switched to the non-reporting mode.

[0148] As described above, the notification image 34 reports the reception of two types of information, invitation information and guidance information. Here, regardless of the type of the received information, the notification image 34 is displayed in a common reporting mode. Note that it is assumed that the notification image 34 displayed in the reporting mode is tapped in the case where both invitation information and guidance information are received. In this case, the invitation information dialog box 52 is displayed on the display 26. That is, the invitation information (invitation information dialog box 52) is displayed preferentially to the guidance information (guidance information dialog box 54).

[0149] However, in the case where both invitation information and guidance information are received, the guidance information (guidance information dialog box 54) can be displayed preferentially to the invitation information (invitation information dialog box 52). Alternatively, the guidance information (guidance information dialog box 54) and the invitation information (invitation information dialog box 52) can be displayed simultaneously. In addition, the notification image 34 can report only the reception of the invitation information. In addition, the notification image 34 can report the reception of the invitation information and the reception of the guidance information in a manner that enables the two to be distinguished from each other. Note that although it is assumed here that the player terminal 1 receives the guidance information, the guidance information is not necessary.

[0150] Here, in this embodiment, when the host player invites an object person and the object person enters the room as a guest player, multiple players can play a multiplayer game for the first time. In addition, only the host player is given the permission to start the multiplayer game. Therefore, when the guest player has entered the room and the multiplayer game is ready to start, and the host player leaves the start tab 50 unchanged without operating the start tab 50, the multiplayer game will never start and the guest player will get moody. For this reason, in this embodiment, in order to reduce the situation where the host player leaves the start tab 50 unchanged, as will be described below, the extraction of the object person at the server 100 and the reception and reporting of the invitation information at the player terminal 1 are performed. Below, first, the method of extracting the object person at the server 100 will be described, and then, the method of receiving and reporting the invitation information at the player terminal 1 will be described.

[0151] (Method for Extracting Object Person)

[0152] Figure 9A It is a diagram for explaining the priority points. Figure 9B It is a diagram for explaining the priority point update conditions. The server 100 stores player information for each player (player ID). The player information includes various information required for playing the game, such as player experience points, player level, player ranking, owned characters, followers, mutual followers, and team information, etc.

[0153] In addition, the player information includes priority information as the information for extracting the object person who has received 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 the preset update conditions.

[0154] In this embodiment, priority points are provided as the priority information. As Figure 9A shown, the maximum value and the minimum value of the priority points are set to 999 points and 0 points respectively, and are updated within the range of 0 - 999. In addition, the priority points are set to 100 points as its initial value, and when the specified update conditions are met, the priority points are updated to the initial value.

[0155] When the random tab 48c is tapped when creating a room, the server 100 randomly extracts the object person who can receive the invitation information from all players. At this time, the server 100 preferentially sets the player with higher priority points as the object person. Therefore, for the player with higher priority points, it is easier to receive the invitation information.

[0156] As Figure 9BThe priority point update conditions are set as follows. Specifically, when a player, as the target person, receives an invitation message, "4" is subtracted from the priority point of the target person. In addition, when the target person taps the notification image 34 to open the invitation message dialog box 52 after receiving the invitation message, "1" is added to the priority point of the target person.

[0157] In addition, when the target person taps the participation tab 52a of the invitation message dialog box 52 to perform a participation operation but cannot participate in the multiplayer game, "4" is added to the priority point of the target person. Note that as cases where the target person cannot participate in the multiplayer game, there are the following cases: the case where the target person cannot enter the room because a game is being played or the room is full; and the case where the room is disbanded before the multiplayer game starts after the target person enters the room. Although it is assumed here that the priority point of the target person is increased when the target person cannot participate in the multiplayer game, instead of this, for example, the priority point of the target person can be increased when the target person cannot enter the room.

[0158] In addition, it is assumed that the battle game of the multiplayer game ends normally (including intermediate termination due to quitting, winning termination, and losing termination). At this time, when the priority point of the guest player at the end of the battle game is greater than the initial value, the priority point of the guest player is reset to the initial value.

[0159] In addition, when a player creates a room as the host player, "4" is subtracted from the priority point of the host player. In addition, at this time, when the random tab 48c is tapped to randomly select the target person who receives the invitation message, "1" is added to the priority point of the host player. In addition, when the multiplayer game starts, "1" is added to the priority point of the host player.

[0160] In addition, when the battle game of the multiplayer game ends as a winning termination or a losing termination, "3" is added to the priority points of all players whose damage inflicted on the enemy character (hereinafter referred to as "the damage inflicted") is greater than or equal to 20% of the total damage.

[0161] According to the above update conditions, for example, when the target person attempts to participate in the multiplayer game but cannot participate in the multiplayer game, "Receive invitation message" (-4), "Open invitation message" (+1), and "Cannot participate in multiplayer game" (+4) are applied, and the priority point of the target person increases by "1" compared to before receiving the invitation message. This enables players who attempt to participate in the multiplayer game but cannot participate in it to more easily receive invitation messages. In addition, when the battle game of the multiplayer game ends normally while the priority point is in a state exceeding the initial value, the priority point is reset to the initial value. This equivalently gives many players the opportunity to receive invitation messages.

[0162] In addition, when the damage caused by a guest player participating in a multiplayer game becomes greater than or equal to 20% of the total damage, "Receive invitation information" (-4), "Open invitation information" (+1), and "Damage caused is greater than or equal to 20%" (+3) are applied, and compared to before participating in the multiplayer game, the priority points of the guest player become positive / negative zero. On the other hand, when the damage caused by the guest player is less than 20% of the total damage, "Receive invitation information" (-4) and "Open invitation information" (+1) are applied, and compared to before participating in the multiplayer game, "3" is subtracted from the priority points of the guest player. That is, the priority of a guest player who does not cooperate in the multiplayer game becomes lower, and it becomes more difficult to set this guest player as the target. In this way, by changing the priority points based on the game results of the communication game, cooperative players are more likely to be set as the target.

[0163] In addition, although "4" is subtracted from the priority points of the host player when creating a room, if the multiplayer game starts and the damage caused by the host player becomes greater than or equal to 20% of the total damage, the priority points of the host player will not decrease. Specifically, in the case of randomly selecting the target, "Create room" (-4), "Randomly select the target" (+1), "Start multiplayer game" (+1), and "Damage caused is greater than or equal to 20%" (+3) are applied, and compared to before creating the room, the priority points of the host player increase by "1". In addition, in the case where the target is set as a follower or a mutual follower, "Create room" (-4), "Start multiplayer game" (+1), "Damage caused is greater than or equal to 20%" (+3) are applied, and compared to before creating the room, the priority points of the host player become positive / negative zero. Therefore, in the case where a player appropriately starts a multiplayer game and plays cooperatively as the host player, this player is considered an excellent player, and an opportunity to participate in the multiplayer game as a guest player is also ensured for this player.

[0164] On the other hand, in the case where the host player creates a room but does not start the multiplayer game, for example, "Create room" (-4) and "Randomly select the target" (+1) are applied, and compared to before creating the room, the priority points of the host player decrease by "3". In addition, also in the case where the damage caused by the host player is less than 20% of the total damage, for example, "Create room" (-4), "Randomly select the target" (+1), and "Start multiplayer game" (+1) are applied, and compared to before creating the room, the priority points of the host player decrease by "2". Therefore, it becomes more difficult for a player who leaves the room as it is, intentionally disbands the room, or does not cooperate to participate in the multiplayer game as a guest player.

[0165] In this embodiment where the update conditions are set as described above, it becomes easier for players considered to be cooperative or excellent to receive invitation information, and appropriate matching can be achieved. Below, the processing executed by the server 100 when setting the target from all players will be described.

[0166] (List update processing at the server 100)

[0167] Figure 10 is the first diagram for explaining the list update processing. The storage unit 118 of the server 100 is equipped with a player information storage unit 160 that stores player information for each player (see Figure 27 ). Each time the server 100 executes communication with the player terminal 1, it executes player information update processing for updating the player information in the player information storage unit 160. In addition, an extraction list is provided in the storage unit 118. The server 100 always executes list update processing for updating the extraction list based on the player information in the player information storage unit 160.

[0168] For example, in the extraction list provided in the storage unit 118, as Figure 10 shown, players (player IDs), invitation information (room numbers), status flags, and waiting times are set in each of many storage areas assigned with addresses. Note that the extraction list shown as Figure 10 and the information to be set in the extraction list are merely examples. For example, priority points and player rankings are not required as the information to be set in the extraction list, and the information to be set in the extraction list can be appropriately designed. In addition, in Figure 10 , the numbers listed as addresses correspond to the priority order, and the storage areas with smaller numbers have higher priority orders.

[0169] In addition, an extraction list is provided for each player ranking. For example, multiple extraction lists are provided, such as an extraction list listing players ranked 1 - 10 and an extraction list listing players ranked 11 - 20, etc. Here, the explanation will be made by using the extraction list listing players ranked 11 - 20.

[0170] In the extraction list, players with higher priority points are listed in the storage area assigned a higher priority order address. For example, assume that the highest priority point among players ranked 11 - 20 is "165". Further assume that there are five players with the highest priority points. In this case, the player information of the players with "165" priority points is set in the storage areas at addresses 1 - 5. Note that in the case of multiple players with the same priority point, the address (priority order) is determined according to the specified conditions. As described above, in the list update process, a process is executed to list the players in descending order of priority points based on the player information in the player information storage unit 160 in the extraction list.

[0171] Figure 11 This is the second figure for explaining the list update process. For example, assume that one of the player terminals 1 sends a request message for requesting the creation of a room and the sending of invitation information. Note that this request message is provided for each of the follower tab 48a, mutual follower tab 48b, and random tab 48c in an identifiable manner. When the request message is received, the server 100 executes a room setting process for creating and setting a room. At this time, when the received request message is a request message for the random tab 48c, the target person is set as follows in the list update process.

[0172] That is, as Figure 11 shown, invitation information is sequentially set in a specified number (100 in this case) of storage areas assigned a higher priority order address. However, the storage area in which the invitation information is set is determined based on the status flag.

[0173] Specifically, the status flag is used to identify the reception status of the invitation information, and here, the reception status is identified as one of the four reception statuses: "can set", "can receive", "cannot receive", and "already received". The reception status "can set" indicates that invitation information can be set. When the storage area where the status flag is to be stored is blank (when the status flag is off), the reception status of the storage area is set to "can set". Further, the reception status "can receive" indicates that when a reception confirmation is made on the player terminal 1 set as the target person (hereinafter referred to as the "target person terminal"), the reception of the set invitation information is permitted. In addition, the reception status "cannot receive" indicates that when a reception confirmation is made on the target person terminal, the reception of the set invitation information is restricted. In addition, the reception status "already received" indicates that the target person terminal has received the invitation information.

[0174] Server 100 sequentially searches for a storage area with a higher-priority assigned address where the reception status is "can be set" (i.e., the status flag is blank), and sets the invitation information in these storage areas. For example, in Figure 10 the state shown, the status flags of all storage areas with addresses 1 - 100 are blank. In this state, when request information for the random tab 48c is received from player terminal 1 of a player with a player rank of 11 - 20, as Figure 11 shown, the invitation information is set in the storage areas with addresses 1 - 100.

[0175] In addition, a status flag is set in the storage area where the invitation information is set. At this time, a status flag indicating "can receive" is set in the storage area with the highest priority point among the storage areas where the invitation information is set. In addition, a status flag indicating "cannot receive" is set in other storage areas where the invitation information is set. In addition, a waiting time is set in each storage area where the status flag "cannot receive" is set.

[0176] The waiting time is the time until the reception status switches from "cannot receive" to "can receive". That is, when the status flag "cannot receive" is set, when the waiting time has elapsed, the status flag switches to "can receive". The storage areas are grouped by priority point, and the same waiting time is set in the storage areas classified into the same group. In addition, a shorter waiting time is set in the group with a higher priority point compared to the group with a lower priority point.

[0177] In Figure 11 the example shown. For the group with "164" priority points, the waiting time is set to 5 seconds, and for the group with "163" priority points, the waiting time is set to 10 seconds. In this way, the waiting time becomes shorter as the priority point increases, and becomes longer as the priority point decreases.

[0178] Figure 12 is the third figure for explaining the list update process. Assume: For example, as Figure 11 shown, after 5 seconds have elapsed after setting the invitation information, status flags, and waiting times. As described above, for the storage areas with addresses 6 - 99, the waiting time is set to 5 seconds. When the 5 - second waiting time has elapsed, as Figure 12 shown, the status flags of the storage areas with addresses 6 - 99 switch to "can receive". Note that for the storage area with address 100 where the waiting time was initially set to 10 seconds, its reception status remains "cannot receive", and the waiting time is updated to 5 seconds.

[0179] As described above, in the case where the reception status is "cannot receive", the invitation information is set, but the player terminal 1 cannot receive the invitation information. That is, even if the player terminal 1 performs reception confirmation in the state where the invitation information is set, the player terminal 1 does not receive the invitation information. In this way, when setting the target person by setting the invitation information, the server 100 allows players with higher priority points to receive the invitation information earlier. This makes it easier for players with higher priority orders to participate in multiplayer games.

[0180] In addition, assume that in the above state, another player terminal 1 newly sends request information for the random tab 48c. In this case, as Figure 12 shown, the invitation information is set in the storage area with addresses 101 - 200. Note that all storage areas with addresses 101 - 200 have 163 priority points. Therefore, here, the status flag "can receive" is set in all storage areas with addresses 101 - 200.

[0181] Figure 13 is the fourth figure for explaining the list update process. For example, assume that in the Figure 12 shown state, the object terminal of the object person set to the storage areas with addresses 1 and 3 performs reception confirmation of the invitation information. In this case, the object terminals of the two players receive the invitation information set in the storage area. When the invitation information is received, as Figure 13 shown in the upper figure of, the server 100 switches the status flag from "can receive" to "received".

[0182] In addition, as described above, when the object person receives the invitation information, "4" is subtracted from the priority point of the object person. The server 100 updates the priority points of the storage areas with addresses 1 and 3 to "161". Then, the server 100 performs a sorting process based on the priority points. As a result of this sorting process, as Figure 13 shown in the lower figure of, the information stored in the storage areas with addresses 1 and 3 moves to an address (storage area) with a lower priority order.

[0183] Note that, as will be described in detail later, in the case of sending request information for the follower tab 48a, the invitation information is set in the storage area of the player set as a follower. In addition, in the case of sending request information for the mutual follower tab 48b, the invitation information is set in the storage area of the player set as a mutual follower.

[0184] Through the above list update process, players with higher motivation to participate in multiplayer games are more likely to receive the invitation information. By having players with higher motivation receive the invitation information, the time until the start of the multiplayer game becomes shorter.

[0185] In addition, in this embodiment, invitation information is received according to the game-playing situation at the player terminal 1. Specifically, when the player is playing a battle game (single-player game) or when it is considered that the player is gazing at the screen to play the game, the reception of the invitation information is reported. That is, when it is considered that the player has a high motivation to participate in a multiplayer game and the player has a high responsiveness to the invitation, the reception of the invitation information is reported to the player terminal 1. This shortens the time until the players participating in the multiplayer game have gathered, thereby making it possible to shorten the time until the multiplayer competition starts.

[0186] (Game state of player terminal 1)

[0187] Figure 14A It is a diagram for explaining the game state of the player terminal 1. Figure 14B It is a diagram for explaining the timing of receiving confirmation of the invitation information. The player terminal 1 updates the game state based on the game-playing situation and the reception situation of the invitation information. As Figure 14A shown, the player terminal 1 manages five game states: the receivable state, the unopened state, the opened state, the participating state, and the non-receivable state. That is, at the player terminal 1, the game state is set to one of the above five game states. The player terminal 1 performs processing related to the reception of the invitation information based on the set game state.

[0188] The receivability of the invitation information is associated with each game state. When the game state is set to the receivable state or the unopened state, the player terminal 1 can receive the invitation information from the server 100. That is, the receivable state and the unopened state in the game state are considered to be permission states that permit the reception of the invitation information. On the other hand, when the game state is set to the opened state, the participating state, or the non-receivable state, the player terminal 1 does not receive the invitation information from the server 100. That is, the opened state, the participating state, and the non-receivable state in the game state are considered to be impossible states in which the reception of the invitation information cannot be performed.

[0189] For example, assume that the player is set as the target at the server 100 and invitation information for the player is set in the server 100. At this time, if the game state at the player terminal 1 is set to the receivable state or the unopened state, the player terminal 1 receives the invitation information from the server 100. On the other hand, even if the invitation information is set in the server 100, if the game state is set to the opened state, the participating state, or the non-receivable state, the player terminal 1 does not receive the invitation information from the server 100. In other words, when the game state is set to the opened state, the participating state, or the non-receivable state, the player terminal 1 does not perform the reception confirmation of the invitation information.

[0190] Note that, although detailed description will be omitted, even when the game state is the permission state, there are cases where the player terminal 1 does not receive the invitation information according to the set invitation information. For example, in the case where a player participates in a battle game of a multiplayer game as a guest player, after the multiplayer game in which the player participates ends, during a 60-minute period, the player does not receive invitation information for a battle game of the same type as the above-mentioned battle game. Thus, although invitation information can basically be received when the game state is the permission state, the reception of certain types of invitation information can be restricted according to the content of the invitation information.

[0191] As Figure 14A shown, setting conditions are provided for each of the above game states. The player terminal 1 determines whether the setting conditions are satisfied and sets the game state based on the result of the determination. As the setting conditions for the receivable state, conditions of not receiving invitation information, conditions that the player has not entered a multiplayer game room, and conditions of not satisfying the setting conditions for the non-receivable state described later are provided. As the setting conditions for the unopened state, conditions of receiving invitation information and conditions of not opening the invitation information dialog box 52 are provided.

[0192] As the setting conditions for the opened state, conditions of displaying the invitation information dialog box 52 and conditions of inputting a shelving operation (tapping the shelving tab 52c of the invitation information dialog box 52) are provided. As the setting conditions for the participating state, conditions that the player is currently in a multiplayer game room are provided. As the setting conditions for the non-receivable state, conditions of not having passed 5 minutes after the normal termination of a multiplayer game and conditions of not having passed a specified time after a rejection operation are provided. Note that, in the case of inputting two rejection operations within 30 minutes, the non-receivable state is maintained during a 60-minute period after the second rejection operation, and in other cases, the non-receivable state is maintained during a 5-minute period after the rejection operation.

[0193] When the game state is set to the permission state, the player terminal 1 makes a reception confirmation of invitation information for the server 100. At this time, if invitation information for the player terminal 1 is set, the player terminal 1 receives the set invitation information. That is to say, when making a reception confirmation of invitation information, the reception of the invitation information is triggered. Therefore, strictly speaking, it is considered whether reception confirmation of invitation information can be performed in advance for each game state.

[0194] As described above, at server 100, players with high motivation to participate in a multiplayer game are set as the target players. However, there are cases where, depending on the gaming situation at player terminal 1, even such highly motivated players cannot immediately participate in the multiplayer game. For example, when moving in a short period of time, or immediately after the termination of a multiplayer game, etc., the motivation to participate in the multiplayer game becomes low. If a player participates in a multiplayer game in a state of low motivation to participate, the player may play the game uncooperatively.

[0195] In this embodiment, invitation information is received according to the gaming situation at player terminal 1. That is, even if the invitation information is set in server 100, according to the gaming situation at player terminal 1, the invitation information is not received. That is, in a situation where the possibility of a player not participating in the multiplayer game is high, player terminal 1 does not even receive the invitation information. This reduces the possibility of a player with low motivation to participate in the multiplayer game from participating in the multiplayer game. In addition, since a player will not receive the invitation information multiple times in a state where the player cannot participate in the multiplayer game, the player can be prevented from being bothered.

[0196] Here, as Figure 14B shown, confirmation of receipt of invitation information at player terminal 1 is performed. That is, when a battle screen is displayed on the display 26 of player terminal 1, confirmation of receipt of invitation information is performed every 15 seconds. However, when a normal screen (a screen other than the battle screen) on the display 26 changes to a battle screen, the first timing for performing confirmation of receipt of invitation information after the screen change is randomly determined to be 1 - 15 seconds by lottery.

[0197] In addition, when a normal screen (a screen other than the battle screen) is displayed on the display 26 of player terminal 1, confirmation of receipt of invitation information is performed every 10 seconds. However, on the display 26, when the battle screen changes to a normal screen, when a normal screen changes to another normal screen, or when there is a page change in the normal screen, the first timing for performing confirmation of receipt of invitation information after the screen change is randomly determined to be 1 - 10 seconds by lottery.

[0198] As described above, by randomly determining the first timing for performing confirmation of receipt of invitation information after a screen change, it is possible to prevent a player from performing an operation to change the screen to only receive invitation information. This suppresses unnecessary communication with server 100, thereby reducing the load on server 100.

[0199] In addition, the time interval for confirmation of receipt of invitation information when a battle screen is displayed is set longer than that when a normal screen is displayed. This suppresses unnecessary execution of a battle game to receive invitation information, thereby making it possible to suppress an increase in the load on server 100.

[0200] Next, the communication processing between the player terminal 1 and the server 100 for executing the above multi-player game will be described. Note that examples of the basic communication processing for the progress of the game and the main communication processing related to the multi-player game will be described here, and descriptions of other types of processing will be omitted.

[0201] (Communication processing between the player terminal 1 and the server 100)

[0202] Figure 15 It is a sequence diagram for explaining the basic processing of the player terminal 1 and the server 100. Note that in the following description, without distinguishing between the host terminal, guest terminal, and subject terminal, the processing at the player terminal 1 is indicated as Pn (n is an arbitrary integer). In addition, the processing at the server 100 is indicated as Sn (n is an arbitrary integer). When the player starts the game application at the player terminal 1 (P1), the login information is sent from the player terminal 1 to the server 100. When the login information is received, the server 100 identifies the player terminal 1 and performs the login processing (S1). Here, the server 100 allows the identified player terminal 1 to download the player information corresponding to the player terminal 1 from the storage unit 118.

[0203] In addition, when the game state is the permission state, the player terminal 1 confirms the reception of invitation information at a prescribed time interval (P2). Here, the player terminal 1 sends the reception confirmation information to the server 100. When the reception confirmation information is received, the server 100 searches for the invitation information for the player terminal 1 in the extraction list (S2). At this time, if the invitation information is set and the reception status is set to "can receive", the player terminal 1 receives the invitation information. When the invitation information is received, the player terminal 1 displays the notification image 34 in the report mode and reports that the invitation information has been received (P3).

[0204] In addition, it is assumed that at the player terminal 1, the single-player game tab 40a is tapped in the game content selection screen (see Figure 4A ) and an operation for starting the single-player game is performed (P4). In this case, the start information is sent from the player terminal 1 to the server 100. Note that the start information includes information related to the team selected by the player, battle game type information, etc. When the start information is input, the server 100 performs the battle game start processing (S3) required to start the battle game. Here, for example, the server 100 secures an area in the memory 112 for the progress of the battle game, stores the information input from the player terminal 1, and reads a prescribed program from the storage unit 118 into the memory 112. In addition, the server 100 makes settings so that the player terminal 1 can receive the data required for the execution of the battle game.

[0205] In addition, the player terminal 1 also executes a battle game start process (P5) required to start the battle game. Here, for example, the player terminal 1 secures an area in the memory 12 for the progress of the battle game, stores play game information, and stores the programs and image data downloaded from the server 100 in the memory. Note that programs and the like required for the battle game can be read from the storage unit 18 into the memory 12.

[0206] When the preparation for the battle game is completed as described above, both the player terminal 1 and the server 100 execute a battle game control process (P6, S4) for parallelly and simultaneously controlling a single-player battle game. In this battle game control process, an update process for updating various information is repeatedly executed in units of frames. Note that the number of frames is not particularly limited, and the number of frames within one second is, for example, 30 - 60. Therefore, in the battle game, the player terminal 1 and the server 100 update information at intervals of approximately 16 ms (milliseconds) to 33 ms.

[0207] In addition, in the update process, transmission and reception of update information are performed between the player terminal 1 and the server 100. Here, although the update process and the transmission and reception of update information are performed in units of frames, the update process and the transmission and reception of update information can be performed at a cycle shorter or longer than the cycle in units of frames. In addition, also when executing the battle game of the single-player game, reception confirmation of invitation information (P7) at the player terminal 1, search for invitation information (S5) at the server 100, and report of reception of invitation information (P8) at the player terminal 1 can be periodically executed. Then, when the battle game termination condition is satisfied, the player terminal 1 and the server 100 each execute a termination process (P9, S6) for terminating the battle game. In the termination process of the player terminal 1 (P9), for example, a result screen is displayed on the display 26. In addition, in the termination process of the server 100 (S6), for example, various player information such as items obtained in the battle game, player experience points, and character experience points is updated.

[0208] Figure 16 It is a sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the case of executing a multiplayer game. Note that in the following description, the processing at the host terminal is indicated as HPn (n is an arbitrary integer), and the processing at the target terminal and the guest terminal is indicated as GPn (n is an arbitrary integer).

[0209] Assume that at the player terminal 1 (owner terminal), the room creation tab 46 is tapped and a request operation (HP10) is input. When the request operation is input, the player terminal 1 (owner terminal) sends request information for requesting the creation of a room and the sending of invitation information to the server 100. Note that the request information includes information related to the group selected by the player, information indicating the type of battle game, information indicating the operation unit that was tapped, etc.

[0210] Upon receiving the request information, the server 100 performs a point update process for updating the priority points in the player information storage unit 160 (shown as "UPDATE" in the figure). Here, "4" is subtracted from the priority points of the owner player who sent the request information. In addition, as will be described in detail later, when the point update process is performed in the player information storage unit 160, similar to the player information storage unit 160, the priority points in the extraction list are also updated. In addition, in the extraction list, a sorting process is performed based on the updated priority points.

[0211] In addition, upon receiving the request information, the server 100 performs a room setting process (S10) for creating and setting a room. Here, a processing area for performing a multiplayer game is ensured, that is, a room is ensured, and various information included in the request information is stored in the room. In addition, the room number of the created room is set. The owner terminal receives the room setting information set in the room setting process and displays the room details page on the display 26 (HP11).

[0212] In addition, the server 100 sets the target person (S11). Here, the invitation information, the status flag, and the counter value of the waiting counter are set in the extraction list to set the target person. Then, when the target person terminal confirms the reception of the invitation information (GP10), the reception confirmation information is sent to the server 100. Upon receiving the reception confirmation information, the server 100 searches to see if invitation information is set for the target person (S12). Here, since the invitation information is set, the server 100 updates the reception status (status flag) of the target person to "received". In addition, the server 100 performs a point update process, and subtracts "4" from the priority points of the target person who received the invitation information.

[0213] When the invitee terminal receives the invitation information, it will display the notification image 34 in the reporting mode and report that the invitee terminal has received the invitation information (GP11). In addition, the invitee terminal updates the game state from the receivable state to the unopened state (GP12). Then, when the invitee taps on the notification image 34 and opens the invitation information dialog box 52 (GP13), the open information is sent to the server 100. When the server 100 receives the open information, the server 100 performs point update processing. Here, "1" is added to the priority points of the invitee. In addition, at the invitee terminal, the game state is updated to the opened state (GP14).

[0214] Then, when the participation tab 52a of the invitation information dialog box 52 is tapped at the invitee terminal, the participation information is sent from the invitee terminal to the server 100 (GP15). Note that the participation information includes information related to the team set by the invitee, etc. When the server 100 receives the participation information, it determines whether it is possible to enter the room, and if it is possible to enter the room, it updates the room information (S13). Here, at the server 100, the updated room information (room update information) is set to be received by the host terminal and the invitee terminal.

[0215] Note that although Figure 16 a single invitee terminal (guest terminal) is shown, the same processing for a single room is performed at multiple invitee terminals (guest terminals). Therefore, in the case where one of the invitee terminals enters the room, all the player terminals 1 of the players in the room receive the room update information.

[0216] When the host terminal receives the room update information from the server 100, it updates and displays the room details page (HP12). In addition, the invitee terminal also receives the room update information. Note that here, the player terminal 1 (invitee terminal) after receiving the room update information is referred to as the guest terminal. When the guest terminal receives the room update information, it updates the game state to the participating state (GP16) and displays the room details page on the display 26 (GP17).

[0217] Then, when the start tab 50 of the room details page is tapped at the host terminal to input an operation to start a multiplayer game (HP13), the start information is sent to the server 100. When the start information is input, the server 100 performs point update processing. Here, "1" is added to the priority points of the host player.

[0218] In addition, the host terminal, the server 100, and the guest terminal each execute the above-described battle game start process (not shown), and then execute a multiplayer game control process (HP14, S14, GP18) for simultaneously controlling a multiplayer game in parallel. In this multiplayer game control process, an update process for updating various information is repeatedly executed in units of frames. In this update process, update information is transmitted and received between the host terminal, the guest terminal, and the server 100. Then, when the battle game termination condition is satisfied, the host terminal, the guest terminal, and the server 100 each execute a termination process (HP15, S15, GP19) for terminating the battle game.

[0219] When the multiplayer game terminates, the server 100 calculates the damage caused by each player participating in the multiplayer game with respect to the total damage (S16). Then, the server 100 executes a point update process based on the calculated damage caused. Here, “3” is added to the priority points of the players whose damage caused is greater than or equal to 20% of the total damage. On the other hand, at the guest terminal, when the multiplayer game terminates, the game state is updated to a non-receivable state (GP20). Then, at the guest terminal, when a predetermined time has elapsed, the game state is updated to a receivable state (GP21).

[0220] Figure 17 is a sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the case where participation in the multiplayer game is not possible. Note that in Figure 17 since the processing until the participation information is input from the target terminal is the same as the processing in Figure 16 this processing will be omitted. As described above, when the participation information is received, the server 100 determines whether it is possible to enter the room. At this time, if it is not possible to enter the room, the server 100 sets non-participation information indicating that entry into the room is not possible. In addition, at this time, the server 100 executes a point update process and adds “4” to the priority points of the target.

[0221] When the non-participation information is received, the target terminal displays a predetermined non-entry room screen on the display 26 (GP22). In addition, the player terminal 1 of the target updates the game state to a receivable state (GP23).

[0222] Figure 18 is a sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the case where participation in the multiplayer game is rejected. Note that in Figure 18 since the processing until the rejection information is input from the target terminal is the same as the processing in Figure 16This processing is the same as that in the object terminal, so the description of this processing will be omitted. When the reject tab 52b of the invitation information dialog box 52 is tapped at the object terminal, a rejection message (GP24) is sent from the object terminal to the server 100. In addition, at the object terminal, the game state is updated to the non-receivable state (GP25).

[0223] Note that in this embodiment, it is assumed that the server 100 does not perform any specific processing when receiving the rejection message. However, in the case of receiving the rejection message, the server 100 can subtract points from the priority points of the object person, or update the reception status (status flag) in the extraction list, etc.

[0224] Next, the functional structure of the player terminal 1 and the specific processing at the player terminal 1 will be described. Note that hereinafter, the structure and processing related to the invitation information will be described, and the structure and processing not related to the invitation information will not be described.

[0225] (Functional Structure of Player Terminal 1)

[0226] Figure 19 FIG. is a diagram for explaining the structure of the memory 12 of the player terminal 1 and the functions of the player terminal 1 in the form of a computer. The memory 12 is provided with a program storage area 12a and a data storage area 12b. When starting a multiplayer game or before starting a multiplayer game, the CPU 10 stores the terminal-side game control program (module) in the program storage area 12a in advance.

[0227] The terminal-side game control program includes a game execution program 60, a battle game execution program 62, a request information sending program 64, a game state update program 66, an invitation information receiving program 68, an invitation information reporting program 70, an operation permission program 72, and a timing program 74. Note that Figure 19 the programs listed in are merely examples, and many other programs are provided as the terminal-side game control program.

[0228] As a storage unit for storing data, the data storage area 12b is provided with a game information storage unit 80, a game state storage unit 82, and an invitation information storage unit 84. Note that the above storage units are merely examples, and the data storage area 12b is provided with many other storage units.

[0229] The CPU 10 runs each program stored in the program storage area 12a and updates the data in each storage unit in the data storage area 12b. In addition, by running each program stored in the program storage area 12a, the CPU 10 causes the player terminal 1 (computer) to function as the terminal-side game control unit 1A. The terminal-side game control unit 1A includes a game execution unit 60a, a battle game execution unit 62a, a request information sending unit 64a, a game state update unit 66a, an invitation information receiving unit 68a, an invitation information reporting unit 70a, an operation permission unit 72a, and a timing unit 74a.

[0230] Specifically, the CPU 10 runs the game execution program 60 to cause the computer to function as the game execution unit 60a. Similarly, the CPU 10 runs the battle game execution program 62, the request information sending program 64, the game state update program 66, the invitation information receiving program 68, the invitation information reporting program 70, and the operation permission program 72 to cause the computer to function as the battle game execution unit 62a, the request information sending unit 64a, the game state update unit 66a, the invitation information receiving unit 68a, the invitation information reporting unit 70a, the operation permission unit 72a, and the timing unit 74a, respectively.

[0231] The game execution unit 60a controls the progress of games other than the battle game, such as organizing a team and strengthening ally characters, based on the player's operation. Whenever an operation is input to the player terminal 1, the game execution unit 60a sends information corresponding to the operation to the server 100. In addition, the game execution unit 60a updates the information in the game information storage unit 80 when updating game-related information (game information).

[0232] The battle game execution unit 62a is responsible for comprehensively controlling the execution of the battle game. For example, the battle game execution unit 62a sends information to the server 100 based on the operation input to the player terminal 1 and receives various information from the server 100. In addition, the battle game execution unit 62a updates the battle screen based on the operation input to the player terminal 1 and the information received from the server 100. That is, when the specified start conditions are met, the battle game execution unit 62a executes a single-player or multi-player game with other player terminals 1. In addition, when the battle game normally terminates, the battle game execution unit 62a updates the information in the game information storage unit 80.

[0233] When one of the tap operation parts (i.e., the follower tab 48a, the mutual follower tab 48b, and the random tab 48c) is tapped, the request information sending unit 64a sends a request signal corresponding to the operation part to the server 100.

[0234] The game state update unit 66a updates the game state in the game state storage unit 82 based on the invitation information reception status and the game play status.

[0235] When the game state is the permission state, the invitation information reception unit 68a performs reception confirmation of invitation information at the timing set for each screen displayed on the display 26. Specifically, the invitation information reception unit 68a sends reception confirmation information to the server 100, receives the invitation information set in the server 100, and stores the invitation information in the invitation information storage unit 84.

[0236] The invitation information reporting unit 70a switches the notification image 34 to the reporting mode or the non-reporting mode based on whether the invitation information is stored in the invitation information storage unit 84, that is, whether the invitation information is received.

[0237] The operation permission unit 72a displays the invitation information dialog box 52 when the notification image 34 is tapped, thereby enabling the player to input a participation operation, a rejection operation, or a hold operation. Specifically, when the notification image 34 displayed in the reporting mode is tapped, the operation permission unit 72a confirms with the server 100 whether there is a room corresponding to the received invitation information. If there is a room, the operation permission unit 72a displays the invitation information dialog box 52( Figure 6C 、 Figure 7A 、 Figure 7C ) on the display 26. That is, by displaying the participation tab 52a, the rejection tab 52b, and the hold tab 52c in a tappable manner, a participation operation for applying to participate in a multiplayer game, a rejection operation for rejecting participation in a multiplayer game, or a hold operation for holding participation in a multiplayer game can be input.

[0238] The timing unit 74a counts the prohibition time, the reception waiting time, and the rejection time, which will be described later.

[0239] (Specific processing of the player terminal 1)

[0240] Figure 20 is a flowchart for explaining an example of the terminal-side game processing at the player terminal 1. In the terminal-side game processing, the game execution unit 60a executes game progress processing and controls the progress of games other than the battle game (P100). In addition, the battle game execution unit 62a executes control for executing a single-player game or a multiplayer 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-reception processing of invitation information (P130), and multiplayer game termination processing (P140).

[0241] Figure 21 This is a flowchart showing an example of the processing related to room creation at the player terminal 1. When the task screen is displayed on the display 26 (Yes in P110-1), when the room creation tab 46 is tapped to input a request operation (Yes in P110-2), the request information sending unit 64a sends the request information to the server 100 (P110-3). At this time, the terminal-side game control unit 1A displays a prescribed waiting screen on the display 26 (P110-4).

[0242] In addition, when the room setting information is received (Yes in P110-5), the terminal-side game control unit 1A displays the room details page on the display 26 (P110-6). In addition, when the room update information is received (Yes in P110-7), the terminal-side game control unit 1A updates the display of the room details page based on the received room update information (P110-8).

[0243] In addition, when the start tab 50 is tapped to input a start operation (Yes in P110-9), the terminal-side game control unit 1A sends the start information to the server 100 (P110-10) and waits until the multiplayer game starts (P110-11). Note that when the multiplayer game can start, in the above-described battle game execution processing (P101), the control of the multiplayer battle game is executed.

[0244] Figure 22 This is a flowchart showing an example of the invitation information reception processing at the player terminal 1. When the screen on the display 26 has changed (Yes in P120-1), the timing unit 74a confirms the screen displayed on the display 26 (P120-7) and determines the initial counter value by lottery (P120-8). Note that the initial counter value indicates the time interval for receiving confirmation of the invitation information. Here, if a normal screen is displayed, a value corresponding to 1 to 10 seconds is determined as the initial counter value, and if a battle screen is displayed, a value corresponding to 1 to 15 seconds is determined as the initial counter value. The timing unit 74a stores the determined initial counter value in a prescribed storage unit (initial value storage unit) in the data storage area 12b and sets the determined initial counter value to the reception standby counter (P120-9).

[0245] In addition, when the screen of the display 26 has not changed (No in P120-1), and the game state stored in the invitation information storage unit 84 is in a non-receivable state (No in P120-2, Yes in P120-3), the timing unit 74a decrements the counter value of the prohibition time counter (P120-4). As will be described in detail later, note that when a rejection operation is performed, a prescribed counter value is set in the prohibition time counter. That is, the prohibition time counter counts the time elapsed after the input of the rejection operation. When the counter value of the prohibition time counter is updated to zero (Yes in P120-5), the game state update unit 66a updates the game state in the game state storage unit 82 to a receivable state (P120-6).

[0246] By doing so, the game state is maintained in a non-receivable state until a prescribed time has elapsed after the rejection operation. Then, when a prescribed time has elapsed after the rejection operation, the game state is switched to a receivable state. Note that when the game state is switched to a receivable state, similar to the above case, the initial counter value is determined based on the screen displayed on the display 26, and the determined initial counter value is set in the reception standby counter (P120-7 to P120-9).

[0247] In addition, when the screen on the display 26 has not changed (No in P120-1), and the game state stored in the invitation information storage unit 84 is in a receivable state or an unopened state (Yes in P120-2), the timing unit 74a decrements the counter value of the reception standby counter (P120-10). Then, when the counter value of the reception standby counter becomes zero (Yes in P120-11), the timing unit 74a sets the initial counter value stored in the initial value storage unit in the reception standby counter again. In addition, the invitation information reception unit 68a executes an invitation information confirmation process (P121).

[0248] Figure 23It is a flowchart for explaining an example of the invitation information confirmation process at the player terminal 1. The invitation information receiving unit 68a sends a reception confirmation message to the server 100 (P121-1). When it is possible to receive (not received) 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 invitation information in the invitation information storage unit 84 (P121-3). In addition, the invitation information receiving unit 68a updates the game state in the game state storage unit P121 to the unopened state (P121-4). In addition, the invitation information reporting unit 70a displays the notification image 34 in the header display area 30 in the reporting mode (P121-5).

[0249] Figure 24 It is the first flowchart for explaining an example of the post-processing after receiving invitation information at the player terminal 1. Figure 25 It is the second flowchart for explaining an example of the post-processing after receiving invitation information at the player terminal 1. When the invitation information is stored in the invitation information storage unit 84 (Yes in P130-1) and the notification image 34 is tapped (Yes in P130-2), the invitation information receiving unit 68a displays the invitation information dialog box 52 on the display 26 (P130-3). At this time, if the game state is the unopened state (Yes in P130-4), the invitation information receiving unit 68a sends an opening message to the server 100 (P130-5). In addition, the game state updating unit 66a updates the game state to the opened state (P130-6).

[0250] In addition, in the state where the invitation information is stored in the invitation information storage unit 84 and the invitation information dialog box 52 is displayed, when the participation tab 52a is tapped to input a participation operation (Yes in P130-1, No in P130-2, Yes in P130-7, and Yes in P130-8), the invitation information receiving unit 68a sends participation information to the server 100 (P130-9). Then, the invitation information receiving unit 68a waits until room update information or non-participation information is received (P130-10). In addition, when room update information is received from the server 100 (Yes in P130-11), the game state updating unit 66a updates the game state to the participation state (P130-12), and the invitation information receiving unit 68a displays the room details page on the display 26 (P130-13). In addition, here, the invitation information receiving unit 68a switches the notification image 34 to the non-reporting mode.

[0251] On the other hand, in the case where the information that cannot participate is received from the server 100 (being "No" in P130-11), the invitation information receiving unit 68a displays the screen that cannot enter the room on the display 26 (P130-14), and deletes the invitation information from the invitation information storage unit 84 (P130-15). In addition, the invitation information reporting unit 70a switches the notification image 34 from the reporting mode to the non-reporting mode (P130-16). In addition, the game state updating unit 66a updates the game state in the game state storage unit 82 to the receivable state (P130-17).

[0252] In addition, in the state where the invitation information is stored in the invitation information storage unit 84 and the invitation information dialog box 52 is displayed, when the reject tab 52b is tapped to input a rejection operation (being "Yes" in P130-1, "No" in P130-2, "Yes" in P130-7, "No" in P130-8, and Figure 25 being "Yes" in P130-18), the invitation information receiving unit 68a terminates the display of the invitation information dialog box 52 (P130-19). In addition, the invitation information reporting unit 70a terminates the display of the notification image 34 in the reporting mode, and displays the notification image 34 in the non-reporting mode or the operation tab 42 (P130-20).

[0253] In addition, the invitation information receiving unit 68a deletes the invitation information from the invitation information storage unit 84 (P130-21), and the game state updating unit 66a updates the game state to the non-receivable state (P130-22). In addition, the invitation information receiving unit 68a sends the rejection information to the server 100 (P130-23). In addition, the timing unit 74a determines whether the counter value of the rejection time counter is zero (P130-24). Note that the rejection time counter counts the time elapsed after the rejection operation is input. Although the detailed description will be omitted, each time the terminal-side game process is executed, the counter value set in the rejection time counter is decremented. Here, when 30 minutes have elapsed after the rejection operation is input, the counter value of the rejection time counter becomes zero.

[0254] When the counter value of the rejection time counter is zero (i.e., "Yes" in P130-24), that is, when 30 minutes have elapsed after the input rejection operation, the time counting unit 74a sets a counter value corresponding to 5 minutes in the prohibition time counter (P130-25). In addition, when the counter value of the rejection time counter is not zero (i.e., "No" in P130-24), that is, when 30 minutes have not elapsed after the input rejection operation, the time counting unit 74a sets a counter value corresponding to 60 minutes in the prohibition time counter (P130-26). In addition, after setting a counter value of 5 minutes or 60 minutes in the prohibition time counter, the time counting unit 74a sets a counter value corresponding to 30 minutes in the rejection time counter (P130-27).

[0255] With the above processing, by operating the permission unit 72a to display the invitation information dialog box 52 when receiving the report invitation information or after receiving the report invitation information (P130-3), a rejection operation for refusing to participate in a multiplayer game can be input. In addition, after inputting the rejection operation, the game state is maintained as a non-receivable state for 5 minutes (the first time) or 60 minutes (the second time), and after 5 minutes or 60 minutes have elapsed, the game state is updated to a receivable state (P120-6). In addition, when two rejection operations are performed within 30 minutes, invitation information is not received during the 60 minutes after the second rejection operation.

[0256] In addition, in a state where the invitation information is stored in the invitation information storage unit 84 and the invitation information dialog box 52 is displayed, when the hold tab 52c is tapped to input a hold operation (i.e., "Yes" in P130-1, "No" in P130-2, "Yes" in P130-7, "No" in P130-8, "No" in P130-18, and "Yes" in P130-28), the invitation information receiving unit 68a terminates the display of the invitation information dialog box 52 (P130-29).

[0257] Figure 26It is a flowchart showing an example of the multiplayer game termination process at the player terminal 1. When the multiplayer game is terminated (Yes in P140-1), the invitation information receiving unit 68a displays the result screen on the display 26 (P140-2). At this time, when the player participates in the multiplayer game as a guest player (Yes in P140-3), the invitation information receiving unit 68a deletes the invitation information from the invitation information storage unit 84 (P140-4). In addition, the game state update unit 66a updates the game state to the non-receivable state (P140-5), and the invitation information receiving unit 68a sets the counter value corresponding to 5 minutes in the prohibition time counter (P140-6). With this multiplayer game termination process, after the multiplayer game in which the player participates as a guest player is terminated, the game state is maintained as the non-receivable state for 5 minutes (the first period of time).

[0258] Next, the functional structure of the server 100 and specific processes at the server 100 will be described. Note that in the following, the structure and processes related to the setting of the target person who can receive the invitation information will be described, and other structures and processes will not be described.

[0259] (Functional Structure of Server 100)

[0260] Figure 27 It is a diagram for explaining the structure of the memory 112 of the server 100 and the functions of the server 100 in the form of a computer. The memory 112 is equipped with a program storage area 112a and a data storage area 112b. When starting a multiplayer game or before starting a multiplayer game, the CPU 110 stores the server-side game control program (module) in the program storage area 112a in advance.

[0261] 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 Figure 27 the programs listed in

[0262] are only examples, and many other programs are provided as the server-side game control program.

[0263] The CPU 110 runs each program stored in the program storage area 112a and updates the data of each storage unit in the data storage area 112b. In addition, by running each program stored in the program storage area 112a, the CPU 110 causes the server 100 (computer) to function as the 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.

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

[0265] Whenever communicating with the player terminal 1, the player information update unit 140a updates the player information of each player accumulated in the player information storage unit 160. In addition, the player information update unit 140a performs point update processing for updating the priority points in the player information storage unit 160.

[0266] 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 performs sorting processing for swapping the storage areas for storing player information. In addition, the list update unit 142a updates the invitation information, status flag, and waiting counter in the extraction list.

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

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

[0269] (Specific processing of the server 100)

[0270] Figure 28 It is a flowchart showing an example of server - side game processing at server 100. In the server - side game processing, the game execution unit 146a executes a battle game execution process (S100) for executing a battle game. In addition, the player information update unit 140a updates the player information in the player information storage unit 160 based on the information input from the player terminal 1. Further, in the server - side game processing, the server - side game control unit 100A executes a request information reception process (S110), an information update process (S120), a multiplayer game termination process (S130), and a re - sorting process (S140).

[0271] Figure 29 It is a flowchart showing an example of the request information reception process at server 100. In the case of selecting a follower as the person to be invited to the room, that is, when request information for the follower tab 48a is received (yes in S110 - 1 and yes in S110 - 2), the terminal setting unit 144a sets invitation information, a status flag, and the counter value of a waiting counter (hereinafter referred to as "invitation information, etc.") in the storage area of the follower in the extraction list (S110 - 3).

[0272] In the case of selecting a mutual follower 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, and yes in S110 - 4), the terminal setting unit 144a sets invitation information, etc. in the storage area of the mutual follower in the extraction list (S110 - 5).

[0273] Note that when setting invitation information for a follower or a mutual follower, it is not necessarily required to set the counter value of the waiting counter. That is, in the case of setting a follower or a mutual follower as the target person, a state where all target persons can receive invitation information simultaneously can be achieved. In addition, similar to the case of randomly setting target persons, the counter value of the waiting counter can be set based on priority points.

[0274] In the case of selecting to randomly extract the person to be invited to the room, that is, when request information for the random tab 48c is received (yes in S110 - 1, no in S110 - 2, and no in S110 - 4), the terminal setting unit 144a sets invitation information, etc. in the storage area of the top 100 players whose reception status is "can be set" (i.e., the reception flag is blank) in the extraction list (S110 - 6).

[0275] In addition, when randomly setting the target person, the player information update unit 140a adds "1" to the priority points of the host player in the player information storage unit 160 (S110-7). In addition, when a request message is received (Yes in S110-1), the server-side game control unit 100A executes room setting processing for setting a room (S110-8). Here, a room (prescribed 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 message. In addition, here, the server-side game control unit 100A sets room information so that the host terminal can receive the room information. In addition, regardless of the type of the request message, the player information update unit 140a subtracts "4" from the priority points of the host player in the player information storage unit 160 (S110-9).

[0276] Figure 30 It is a flowchart showing an example of information update processing at the server 100. When a reception confirmation message is received from the player terminal 1 (Yes in S120-1), the server-side game control unit 100A searches the extraction list to search for whether invitation information for the player terminal 1 is set (S120-2). At this time, if the invitation information is set (Yes in S120-3) and the reception status (status flag) is set to "can receive" (Yes in S120-4), the server-side game control unit 100A executes invitation information output processing (S120-5). Here, the invitation information is set so that the player terminal 1 that has sent the reception confirmation message can receive the invitation information.

[0277] In addition, the player information update unit 140a subtracts "4" from the priority points of the target person stored in the player information storage unit 160 (S120-6). In addition, the list update unit 142a updates the reception status (status flag) of the target person terminal to "received" in the extraction list.

[0278] In addition, when an open message 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).

[0279] In addition, when the participation information is received from the player terminal 1 (the target terminal) (Yes in S120-10), if it is possible to enter the room (Yes in S120-11), the server-side game control unit 100A updates the room information in the room information storage unit 166 (S120-12). In addition, the server-side game control unit 100A performs room update information output processing. Here, the server-side game control unit 100A sets the room update information so that the host terminal and all guest terminals (including the target terminal that has sent the participation information) can receive the room update information (S120-13).

[0280] On the other hand, if it is not possible to enter the room (No in S120-11), the player information update unit 140a adds "4" to the priority points of the target who has sent the participation information in the player information storage unit 160 (S120-14). In addition, the server-side game control unit 100A sets this target to be able to receive the information that participation is not possible (S120-15).

[0281] In addition, when the 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 performs battle game start processing for starting a multiplayer battle game (S120-18).

[0282] Figure 31 It is a flowchart showing an example of multiplayer game termination processing at the server 100. In the battle game execution process (S100), when the multiplayer game terminates normally instead of terminating in the middle (quitting) (Yes in S130-1 and No in S130-2), the server-side game control unit 100A identifies the players who have caused damage equal to or greater than 20% of the total damage (S130-3). Note that in the battle game execution process (S100), when the multiplayer game is executed, the damage caused by each player is stored in the game information storage unit 164.

[0283] The player information update unit 140a adds "3" to the priority points of the identified players in the player information storage unit 160 (S130-4). In addition, when the multiplayer game terminates, the player information update unit 140a resets the priority points of all players whose priority points are greater than the initial value to the initial value (set to 100) (S130-5).

[0284] Figure 32It is a flowchart for explaining an example of the reordering process at server 100. The list update unit 142a updates the priority points in 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). In addition, the list update unit 142a performs a sorting process for swapping the priority order based on the priority points in the extraction list (S140-2). In this way, the priority order of the players is updated based on the priority points.

[0285] Then, the list update unit 142a performs a list information update process for updating 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 of the storage area whose counter value has been updated to 0 from "cannot receive" to "can receive". In addition, the list update unit 142a updates the status flag of the person who has received the invitation information from "can receive" to "has received". In addition, in the case where the multiplayer game ends, in the case where the room is disbanded, or in the case where a predetermined time has elapsed after the invitation information is set, the list update unit 142a updates the invitation information, the status flag, and the wait counter in the extraction list.

[0286] As described above, in the player terminal 1, a program for executing a multiplayer game as a host terminal and a program for executing a multiplayer game as a guest terminal are provided. In addition, the player terminal 1 serves as a request information sending unit 64a, and the request information sending unit 64a sends request information to the server 100 in response to an input of a request operation from the room creation tab 46 (operation unit). Note that, in this embodiment, the server 100 is provided as an external device, and multiple player terminals 1 can execute a multiplayer game via the server 100 as an external device. However, the external device is not limited to the server 100. For example, the player terminal 1 can be equipped with the functions of the above-mentioned server 100, or one of the player terminals 1 can be used as an external device.

[0287] In addition, the player terminal 1 serves as a game state update unit 66a (state update unit), and the game state update unit 66a updates the game state based on the game situation. Note that, although five game states are provided in this embodiment, the number of game states and the game state setting conditions are merely examples and can be designed appropriately. For example, a login state can be included as a game situation (game state), and the game state can change according to whether the player terminal 1 is logged in. In any case, a permission state in which invitation information can be received and a non-permission state in which invitation information is not received can be provided as game states.

[0288] In addition, in the present embodiment, the game state is set and updated based on the gaming situation and whether an invitation message is received. However, the game state update unit 66a may update the game state based on at least the gaming situation.

[0289] In addition, when the game state of the player terminal 1 is in the permission state, the player terminal 1 serves as an invitation message receiving unit 68a (receiving unit) that can receive an invitation message from the server 100 (external device). Note that in the present embodiment, the invitation message is set at the server 100, and when the player terminal 1 performs reception confirmation, the player terminal 1 receives the invitation message. However, the process performed by the invitation message receiving unit 68a for receiving the invitation message is not limited to this process.

[0290] For example, when an object person is set at the server 100, the server 100 sends the invitation message to the object person's terminal. At this time, if the game state of the object person's terminal is in the permission state, the invitation message can be received, and if the game state is in the impossible state, the reception of the invitation message can be rejected. In any case, when the game state is in the permission state, the invitation message receiving unit 68a can receive the invitation message from the server 100 (external device), and its process or method is not limited.

[0291] In addition, the player terminal 1 serves as an invitation message reporting unit 70a (reporting unit) that reports the reception of the invitation message. In the present embodiment, the invitation message reporting unit 70a reports the reception of the invitation message by switching the display mode of the notification image 34. However, the method for reporting the reception of the invitation message is not limited to this method. For example, the reception of the invitation message can be reported by forcibly displaying the invitation message dialog box 52 when the invitation message is received or after the invitation message is received. In any case, the invitation message reporting unit 70a can report the reception of the invitation message when the invitation message is received or after the invitation message is received, and the reporting mode can be appropriately designed.

[0292] In addition, the player terminal 1 serves as an operation permission unit 72a that enables input of a participation operation. In the present embodiment, the operation permission unit 72a enables input of a participation operation, a rejection operation, and a hold operation by providing a participation tab 52a, a rejection tab 52b, and a hold tab 52c to the invitation information dialog box 52. However, it is sufficient that the operation permission unit 72a enables input of a participation operation, a rejection operation, and a hold operation, and its method or process can be appropriately designed. In addition, it is sufficient that the operation permission unit 72a enables input of at least a participation operation, and there is no need to accept rejection operations and hold operations. In any case, it is sufficient that the operation permission unit 72a enables input of a prescribed participation operation at the time of receiving the report of invitation information or after receiving the report of invitation information.

[0293] In addition, the player terminal 1 serves as a game execution unit 60a that executes a multiplayer game (communication game) with other player terminals 1. Note that the content of the game in the present embodiment is merely an example, and the content of the game is not particularly limited. The content of the game can be, for example, an action game, a role-playing game, a racing game, etc. In any case, it is sufficient that a communication game can be executed at multiple player terminals 1, and the content of the communication game is not particularly limited. Therefore, the content of the communication game can be such that multiple players cooperate with each other or multiple players battle each other. In any case, the game execution unit 60a broadly includes a game execution unit that executes a communication game with other player terminals 1 when a participation operation is input and a prescribed start condition is satisfied.

[0294] In addition, in the present embodiment, the state in which invitation information can be received is the same as the state in which the reception of invitation information can be reported. Therefore, when invitation information is received, the player terminal 1 immediately reports the reception of the invitation information. However, the state in which invitation information can be received can be different from the state in which the reception of invitation information can be reported. For example, it is assumed that the reception confirmation of invitation information is based on the above five game states. In addition, the player terminal 1 serves as a reportability state setting unit that sets the reportability state in a manner separate from the game state. As the reportability state, for example, a reportable state and a non-reportable state are provided.

[0295] For example, the reportability state setting unit switches the reportability state based on the transition of the screen displayed on the display 26. Specifically, when the screen transitions to a screen that can display the notification image 34 in the report mode or the invitation information dialog box 52, the reportability state setting unit sets the reportability state to the reportable state. On the other hand, when the screen transitions to a screen that cannot display the notification image 34 in the report mode or the invitation information dialog box 52, the reportability state setting unit sets the reportability state to the non-reportable state.

[0296] In addition, when receiving the invitation information, the invitation information reporting unit 70a confirms whether the status can be reported, and if the status that can be reported is the reportable status, it displays the notification image 34 in the reporting mode or the invitation information dialog box 52 on the display 26. On the other hand, if the status that can be reported is the non-reportable status when receiving the invitation information, the invitation information reporting unit 70a continues to display the notification image 34 in the non-reporting mode. In this case, even if the invitation information is received, the player is not notified of the existence of the invitation information. In addition, the invitation information reporting unit 70a confirms the status that can be reported at a specified timing (such as when the screen changes, etc.), and if the status that can be reported is the reportable status, it displays the notification image 34 in the reporting mode or the invitation information dialog box 52 at that timing.

[0297] As described above, it is possible to provide a game state that defines the receptivity of invitation information and a reportable status that defines the reportability of the reception of invitation information. In addition, the state in which invitation information can be received can be different from the state in which the reception of invitation information can be reported.

[0298] In addition, the game state can define the report of the reception of invitation information. That is, in the case where the game state is the permission state, the invitation information reporting unit 70a can report the reception of the invitation information when receiving the invitation information or after receiving the invitation information. This modification will be described with reference to the accompanying drawings.

[0299] (Modification)

[0300] Figure 33 is a flowchart for explaining an example of the invitation information reception process at the player terminal 1 in the modification. Instead of the invitation information reception process in the above-described embodiment, the invitation information reception process in this modification is executed. Note that although the detailed description will be omitted, in the case of executing the invitation information reception process in this modification, the processes in the invitation information reception post-processing and the multiplayer game termination processing are partially added or changed in the above-described embodiment.

[0301] The invitation information reporting unit 70a determines whether the screen displayed on the display 26 is a screen on which the reception of invitation information can be reported (P150-1). Note that whether the reception of invitation information can be reported is preset for each screen. In the case where the screen is switched to a screen on which the reception of invitation information cannot be reported (No in P150-1), the game state update unit 66a sets the game state in the game state storage unit 82 to the impossible state (P150-2).

[0302] On the other hand, when the screen displayed on the display 26 is a screen capable of reporting the reception of the invitation information (Yes in P150-1), the game state update unit 66a sets the game state to the permission state (P150-3). At this time, when there is unreported (unreported reception) invitation information stored in the invitation information storage unit 84 (Yes in P150-4), the invitation information reporting unit 70a displays the notification image 34 in the reporting mode (P150-5).

[0303] In addition, the invitation information reception unit 68a sends a reception confirmation message to the server 100 (P150-6) and waits until a message is received from the server 100 (P150-7). When the invitation information is received (Yes in P150-8), the received invitation information is stored in the invitation information storage unit 84 (P150-9). At this time, if the game state is the permission state (Yes in P150-10), the invitation information reporting unit 70a displays the notification image 34 in the reporting mode (P150-11).

[0304] According to the above modification example, regardless of the game playing status (game state), the player terminal 1 receives the invitation information. In addition, when the game state is the permission state, the invitation information reporting unit 70a reports the reception of the invitation information when the invitation information is received or after the invitation information is received. Similarly through this modification example, operations and advantages similar to those in the above embodiment are achieved.

[0305] Note that in the above embodiment, the game state update unit 66a sets the game state to the impossible state where invitation information cannot be received during a 5-minute (first time) period after the termination of the multiplayer game (communication game). In addition, in this modification example, the game state update unit 66a may set the game state to the impossible state where the reception of the invitation information cannot be reported during a specified time (first time) period after the termination of the multiplayer game (communication game).

[0306] In addition, in the above embodiment, the game state update unit 66a sets the game state to the impossible state where invitation information cannot be received during a 5-minute (first time) or 60-minute (second time) period after the input of the rejection operation. In addition, in this modification example, the game state update unit 66a may set the game state to the impossible state where the reception of the invitation information cannot be reported during a specified time (second time) period after the input of the rejection operation.

[0307] In addition, the server 100 accumulates prescribed player information for each player in the player information storage unit 160 (storage unit) and serves as the player information update unit 140a (accumulation unit, update unit), which updates the priority points (priority information) of each player according to preset update conditions. Note that the priority point update conditions can be appropriately designed. In addition, the priority points are merely examples of priority information. For example, the playing time, player level, player ranking, billing amount, or a combination of these items can be set as the priority information.

[0308] Note that in the above embodiment, the player information update unit 140a updates the priority points based on the percentage of damage caused in the multiplayer game. That is, the player information update unit 140a updates the priority points (priority information) based on a prescribed result in the multiplayer game (communication game). In this case, for example, instead of the percentage of damage caused, the priority points can be updated based on whether the player character is alive at the end of the multiplayer game. In addition, for example, the points obtained by multiplying the damage caused by a prescribed coefficient can be added to or subtracted from the priority points. In any case, when updating the priority information based on a prescribed result during the multiplayer game (communication game), the prescribed result can be appropriately designed. However, the result during the multiplayer game is not required as the priority point update condition.

[0309] In addition, in the above embodiment, the player information update unit 140a updates the priority points (priority information) based on the information received from the target terminal (extraction terminal) after receiving the invitation information. Specifically, the priority points are updated in the case of inputting participation information (but unable to enter the room) and in the case of inputting the open information. However, the player information update unit 140a does not need to update the priority points, for example, after receiving the invitation information.

[0310] In addition, when receiving the request information from the player terminal 1, the server 100 serves as the terminal setting unit 144a (setting unit), which can set a plurality of player terminals 1 as target terminals (extraction terminals) capable of receiving invitation information at least based on the priority points (priority information). Note that in the above embodiment, there is a case where the terminal setting unit 144a sets the follower or mutual follower as the target. That is, there is a case where the terminal setting unit 144a sets the target based on the priority points and a case where the terminal setting unit 144a sets the target regardless of the priority points. When setting the priority information for each player, the terminal setting unit 144a can set the target terminal at least based on the priority information.

[0311] In addition, the server 100 functions as a game execution unit 146a that executes a multiplayer game (communication game) between one or more object terminals (extraction terminals) that have received invitation information and sent prescribed participation information and the player terminal 1 (host terminal) that has sent request information. Additionally, the content of the game provided by the game execution unit 146a is not particularly limited.

[0312] In addition, the role sharing between the player terminal 1 and the server 100 described above is merely an example. In the above-described embodiments and variations, the player terminal 1 stores and updates the game state. That is, in the above-described embodiments and variations, the player terminal 1 functions as a game state update unit 66a (state update unit). However, the server 100 may store and update the game state.

[0313] A second embodiment in which the server 100 functions as a state update unit (server-side state update unit) will be described below. Note that in the following description, the same reference numerals will be given to the same structures as those in the above-described embodiment, and the description of these structures will be omitted.

[0314] (Second Embodiment)

[0315] Figure 34 FIG. is a diagram for explaining the structure of the memory 12 of the player terminal 1 in the second embodiment and the functions of the player terminal 1 in the form of a computer. In the second embodiment, in addition to the above program, the terminal-side game control program further includes a game state transmission program 67. Further, the CPU 10 runs the game state transmission program 67 so that the player terminal 1 functions as a game state transmission unit 67a.

[0316] The game state transmission unit 67a transmits the game state (game state information) at the player terminal 1 to the server 100. Note that in the second embodiment, similar to the above-described embodiment, the player terminal 1 sets and updates the game state. At this time, the setting conditions for setting the game state may be the same as or different from the setting conditions in the above-described embodiment. Additionally, although the game state storage unit 82 stores the game state here, the player terminal 1 does not need to store or update the game state. In any case, it is sufficient that the game state transmission unit 67a transmits the game state at the player terminal 1 to the server 100.

[0317] In addition, the conditions for the game state sending unit 67a to send game state information can be appropriately designed. For example, when the game state changes, the game state sending unit 67a sends the game state information corresponding to the changed game state to the server 100. However, the game state sending unit 67a can send the game state information corresponding to the currently set game state to the server 100 at regular intervals. Optionally, the game state sending unit 67a can send the game state information each time communication with the server 100 is executed.

[0318] In addition, in the second embodiment, similar to the above embodiment, five states, namely, "receivable state", "not opened state", "opened state", "participation state", and "non-receivable state", are provided as game states (see Figure 14A ). Therefore, the game state sending unit 67a sends five types of game state information that can be distinguished from each other to the server 100. However, in the second embodiment, the game states can be different from those in the above embodiment. For example, Figure 14A the two types of states, namely, "permission state" and "impossible state" shown, can be set as game states.

[0319] Figure 15 FIG. is a diagram for explaining the structure of the memory 112 of the server 100 in the second embodiment and the functions of the server 100 in the form of a computer. In the second embodiment, in addition to the above programs, the server-side game control program further includes a game state receiving program 147 and a game state updating program 149. In addition, the CPU 110 runs the game state receiving program 147 so that the server 100 functions as a game state receiving unit 147a. In addition, the CPU 110 runs the game state updating program 149 so that the server 100 functions as a game state updating unit 149a.

[0320] The game state receiving unit 147a receives the game state (game state information) sent from the player terminal 1.

[0321] The game state updating unit 149a updates the game state of the player terminal 1 based on the game state information received by the game state receiving unit 147a. Note that the game state can be stored in the player information storage unit 160 or can be stored in the extraction list storage unit 162. In addition, in a manner separate from the player information storage unit 160 and the extraction list storage unit 162, a dedicated storage unit for storing the game states of each player terminal 1 can be set in the data storage area 112b. In the second embodiment, as an example, the case where the game state updating unit 149a stores the game states of each player terminal 1 in the player information storage unit 160 is described.

[0322] In addition, also in the second embodiment, the list update unit 142a sets a status flag in the extraction list. However, in the second embodiment, five status flags, namely, "permission status", "impossible status", "can receive", "cannot receive", and "received", are provided. Among these status flags, "permission status" and "impossible status" are provided in place of "can be set (blank)" in the above-described embodiment, and "can receive", "cannot receive", and "received" are the same as those in the above-described embodiment. The list update unit 142a updates the status flag based on the player status stored in the player information storage unit 160, the operation information input from the player terminal 1, and the game execution and management status at the server 100.

[0323] The list update unit 142a sets the status flag in the extraction list to "permission status" for the player terminal 1 in which the player status stored in the player information storage unit 160 is "can receive status" or "not opened status". In addition, the list update unit 142a sets the status flag in the extraction list to "impossible status" for the player terminal 1 in which the player status stored in the player information storage unit 160 is "opened status", "participation status", or "cannot receive status".

[0324] When the request information for the random tab 48c is received, the terminal setting unit 144a sets invitation information and the like in the storage area of the top 100 players among the players whose status flag in the extraction list is "permission status".

[0325] An example of the processing of the player terminal 1 and the server 100 in the second embodiment will be described below.

[0326] Figure 36A FIG. is a first sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the second embodiment. When the game state is updated at the player terminal 1 (P201), the game state information is sent to the server 100. When the game state receiving unit 147a receives the game state information, the game state updating unit 149a updates the game state in the player information storage unit 160 (S201). In addition, the list update unit 142a updates the status flag in the extraction list based on the game state stored in the player information storage unit 160.

[0327] Figure 36BThis is the second sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the second embodiment. When the combat game control processing of the multiplayer game terminates at the player terminal 1 and the server 100 (P205, S205), the game state update unit 149a updates the game state in the player information storage unit 160 to the "unreceivable state" (S206). In addition, the list update unit 142a updates the status flag in the extraction list to the "impossible state" for the players (at least one of the host player and the guest player) who participated in the multiplayer game (S207). At this time, the list update unit 142a sets the first time in the waiting counter as the waiting time (S208).

[0328] Figure 36C This is the third sequence diagram for explaining the processing of the player terminal 1 and the server 100 in the second embodiment. When a rejection operation is input at the player terminal 1 (P210), the rejection information is sent to the server 100. When receiving the rejection information, the game state update unit 149a updates the game state in the player information storage unit 160 to the "unreceivable state" (S210). In addition, the list update unit 142a updates the status flag in the extraction list to the "impossible state" (S211). At this time, the list update unit 142a sets the second time in the waiting counter as the waiting time (S212).

[0329] Note that although detailed description will be omitted, when the above-mentioned first time or second time has passed, in the list information update process (see Figure 32 ), the list update unit 142a confirms the game state in the player information storage unit 160. At this time, if the game state is the "receivable state" or the "unopened state", the list update unit 142a updates the status flag to the "permitted state". On the other hand, if the game state is not the "receivable state" or the "unopened state", the status flag is maintained as the "impossible state".

[0330] As described above, according to the second embodiment, the server 100 serves as the game state update unit 149a (state update unit). The game state update unit 149a updates the game state of the player terminal 1 based on the information received from the player terminal 1. In addition, the terminal setting unit 144a (setting unit) sets the target terminal (extraction terminal) based at least on the priority points (priority information) and the game playing status at the player terminal 1.

[0331] In addition, in the second embodiment, the terminal setting unit 144a (setting unit) does not set the player terminal 1 that has executed the multiplayer game (communication game) as the target terminal (extraction terminal) at least before the first time has elapsed after the communication game ends. In addition, the terminal setting unit 144a (setting unit) does not set the player terminal 1 that has sent a rejection message indicating refusal to participate in the multiplayer game (communication game) as the target terminal (extraction terminal) at least before the second time has elapsed after receiving the invitation message.

[0332] Note that, in the second embodiment, the player terminal 1 transmits game state information. However, the player terminal 1 does not need to manage the game state, and only the server 100 can update the game state of the player terminal 1 based on the information received from the player terminal 1. In addition, the above modifications can also be applied to the second embodiment.

[0333] In addition, for example, the game state update unit 149a can update the login state of the player terminal 1 to the game situation, that is, the game state. In addition, the terminal setting unit 144a can set the player terminal 1 in the login state as the target terminal, and does not set the player terminal 1 not in the login state as the target terminal.

[0334] Note that, in the above embodiment, in addition to updating the game state at the player terminal 1, the login state can also be updated to the game state at the server 100. In this case, the target is set based on the game state managed at the player terminal 1 and the server 100 and the priority information managed at the server 100.

[0335] As described above, the game situation (that is, the game state) can be managed at the player terminal 1, can be managed at the server 100, or can be managed at both the player terminal 1 and the server 100. However, by managing the game state at the player terminal 1, the processing load on the server 100 is reduced. On the other hand, in the case of managing the game state at the server 100, the server 100 can identify the player terminal 1 that can immediately receive the invitation message or report the reception of the invitation message. Therefore, only the player terminal 1 that can immediately receive the invitation message or report the reception of the invitation message can be set as the target terminal. This enables the multiplayer game to start earlier.

[0336] Note that the information processing program can cause a computer to function as: a player information update unit 140a (update unit) that updates the priority information of each player according to preset update conditions; a terminal setting unit 144a (setting unit) that can set a plurality of player terminals 1 as extraction terminals capable of receiving invitation information at least based on the priority information when receiving request information from the player terminal 1; and a game execution unit 60a that executes a communication game between one or more extraction terminals that have received the invitation information and sent prescribed participation information in the extraction terminals and the player terminal 1 that has sent the request information.

[0337] In addition, the information processing system S may include: a player information update unit 140a (update unit) that updates the priority information of each player according to preset update conditions; a request information sending unit 64a that sends request information in response to the input of a request operation on the operation unit of the player terminal 1; a terminal setting unit 144a (setting unit) that can set a plurality of player terminals 1 as extraction terminals capable of receiving invitation information at least based on the priority information when receiving the request information from the player terminal 1; an invitation information receiving unit 68a (receiving unit) that can receive the invitation information at each extraction terminal; and a game execution unit 146a that executes a communication game between one or more extraction terminals that have received the invitation information and sent participation information based on the input of a prescribed participation operation in the extraction terminals and the player terminal 1 that has sent the request information.

[0338] Note that the player information update unit 140a (update unit) can update the priority information based on a prescribed result in the communication game.

[0339] In addition, the player information update unit 140a (update unit) can update the priority information based on the information received from the extraction terminal after receiving the invitation information.

[0340] In addition, the terminal setting unit 144a (setting unit) can set the extraction terminal at least based on the priority information and the game-playing status at the player terminal 1.

[0341] In addition, the terminal setting unit 144a (setting unit) does not need to set the player terminal 1 that has executed the communication game as an extraction terminal at least before a first time has elapsed after the termination of the communication game.

[0342] In addition, the terminal setting unit 144a (setting unit) does not need to set the player terminal 1 that has sent a rejection message indicating rejection of participation in the communication game as an extraction terminal at least before a second time has elapsed after receiving the invitation information.

[0343] Note that, in the above-described embodiments and variations, the information processing system S as a client-server system performs the above-described respective information processing steps. However, only the player terminal 1 in the above-described embodiments and variations may be provided as the game terminal device. The game terminal device is not limited to a smart phone and may be a dedicated game device including a communication function. Further, only the server 100 in the above-described embodiments and variations may be provided as the server device.

[0344] In addition, the programs in the above-described embodiments and variations may be stored in a computer-readable storage medium and provided as the storage medium. Further, the program may be provided as a game terminal device or a server device including the storage medium. Further, the above-described embodiments and variations may be an information processing method for implementing the respective functions and steps indicated in the flowchart.

[0345] Although the embodiments have been described above with reference to the accompanying drawings, needless to say, the present invention is not limited to the above-described embodiments and variations. Obviously, those skilled in the art can conceive various variations or modifications within the scope recited in the claims, and it should be understood that these variations or modifications naturally belong to the technical scope of the present invention.

[0346] Industrial Applicability

[0347] The present invention is applicable to an information processing program, a game terminal device, and an information processing system.

[0348] Description of Reference Numerals

[0349] 46 Room creation tab (operation unit)

[0350] 60a Game execution unit

[0351] 64a Request information sending unit

[0352] 66a Game state update unit (state update unit)

[0353] 68a Invitation information receiving unit (receiving unit)

[0354] 70a Invitation information reporting unit (reporting unit)

[0355] 72a Operation permission unit

[0356] 100 Server (external device)

[0357] 140a Player information update unit (accumulation unit)

[0358] 144a Terminal setting unit (setting unit)

[0359] 146a Game execution unit

[0360] 149a Game state update unit (state update unit)

[0361] 160 Player information storage unit (storage unit)

[0362] S Information processing system

Claims

1. A computer-readable storage medium stores a program that causes a first player terminal to execute a method, the method comprising: A request information sending step for, in response to an input of a request operation from an operation unit, sending request information to a server, the request information requesting the server to store invitation information in association with a plurality of other player terminals, the invitation information inviting players to a communication game that can be played simultaneously by a plurality of players, and each player terminal associated with the invitation information is set as a receiving terminal capable of receiving the invitation information from the server; A state storage step for storing a game state at least based on a game playing situation, the game state including a permission state allowing reception of the invitation information from the server and an impossible state not allowing reception of the invitation information from the server; A judgment step for judging, based on communication with the server, whether the first player terminal corresponds to one of the receiving terminals stored in response to request information from a second player terminal; A receiving step for, when the permission state is stored as the game state and the first player terminal corresponds to one of the receiving terminals stored in response to request information from the second player terminal, receiving the invitation information from the server; A storage step for storing the received invitation information in a memory of the first player terminal; A reporting step for reporting reception of the invitation information when or after receiving the invitation information; An input receiving step for, when or after reporting reception of the invitation information, receiving an input of a specified participation operation; and A game execution step for, when the specified participation operation is input and a specified start condition is satisfied, executing a communication game with at least the second player terminal, The method further includes: After the communication game ends, setting the game state to the impossible state during a predetermined first time period.

2. The computer-readable storage medium according to claim 1, wherein, The method further includes: Receiving an input of a rejection operation for rejecting participation in the communication game when or after reporting reception of the invitation information; and After receiving the input of the rejection operation, setting the game state to the impossible state during a predetermined second time period.

3. The computer-readable storage medium according to claim 1, wherein, The method further includes: Receiving an input of a specified suspension operation when or after reporting reception of the invitation information; Continuing the reporting when the specified suspension operation is input; and Terminating the reporting when receiving non-participation information that can be received when unable to participate in the communication game.

4. A computer-readable storage medium stores a program that causes a first player terminal to execute a method, the method comprising: A request information sending step, for responding to an input of a request operation from an operation unit, sending request information to a server, the request information requesting the server to store invitation information in association with a plurality of other player terminals, the invitation information inviting a player to a communication game that can be played simultaneously by a plurality of players, and each player terminal associated with the invitation information is set as a receiving terminal capable of receiving the invitation information from the server; A judging step, for judging based on communication with the server whether the first player terminal corresponds to one of the receiving terminals stored in response to request information from a second player terminal; A receiving step, for receiving the invitation information from the server when the first player terminal corresponds to one of the receiving terminals stored in response to request information from the second player terminal; A storing step, for storing the received invitation information in a memory of the first player terminal; A game state storing step, for storing a game state at least based on a game playing condition, the game state including a permission state allowing reporting of the reception of the invitation information from the server and an impossible state not allowing reporting of the reception of the invitation information from the server; A reporting step, for reporting the reception of the invitation information when or after receiving the invitation information when the permission state is stored as the game state; An input receiving step, for receiving an input of a prescribed participation operation when or after reporting the reception of the invitation information; And A game execution step, for executing a communication game with at least the second player terminal when the prescribed participation operation is input and a prescribed start condition is satisfied, The method further includes: After the communication game terminates, setting the game state to the impossible state during a predetermined first time period.

5. The computer-readable storage medium according to claim 4, Wherein, The method further includes: Receiving an input of a rejection operation for rejecting participation in the communication game when or after reporting the reception of the invitation information; and After receiving the input of the rejection operation, setting the game state to the impossible state during a predetermined second time period.

6. The computer-readable storage medium according to claim 4, Wherein, The method further includes: Receiving an input of a prescribed suspension operation when or after reporting the reception of the invitation information; Continuing the reporting when the prescribed suspension operation is input; and Terminating the reporting when receiving non-participation information that can be received when unable to participate in the communication game.

7. A game terminal device, comprising the computer-readable storage medium according to any one of claims 1 to 6.

8. An information processing system, including a server and a plurality of player terminals including a first player terminal, The server is configured to execute: An accumulation step for accumulating prescribed player information for each player in a storage unit; the first player terminal is configured to execute: A request information sending step for sending request information to the server in response to an input of a request operation on an operation unit of the first player terminal, the request information requesting the server to store invitation information in association with a plurality of other player terminals among the plurality of player terminals, the invitation information inviting a player to a communication game that can be played simultaneously by a plurality of players ； And A state storage step for storing a game state at least based on a game playing status, the game state including a permission state allowing reception of the invitation information from the server and an impossible state not allowing reception of the invitation information from the server; The server is further configured to execute: A storage step for, in a case where the request information is received from one of the plurality of player terminals, storing the plurality of player terminals in association with the request information at least based on the prescribed player information accumulated in the storage unit, and each player terminal associated with the invitation information is set as a receiving terminal capable of receiving the invitation information from the server; The first player terminal is further configured to execute: A determination step for determining, based on communication with the server, whether the first player terminal corresponds to one of the receiving terminals stored in response to request information from another player terminal among the plurality of player terminals; A reception step for receiving the invitation information from the server in a case where the permission state is stored as the game state and the first player terminal corresponds to one of the receiving terminals stored in response to request information from another player terminal among the plurality of player terminals; A storage step for storing the received invitation information in a memory of the first player terminal; A reporting step for reporting reception of the invitation information when or after receiving the invitation information; and An input reception step for receiving an input of a prescribed participation operation when or after reporting reception of the invitation information; and The server is further configured to execute: A game execution step for executing a communication game between at least one player terminal that has sent participation information based on an input of the prescribed participation operation among the plurality of player terminals and the player terminal that has sent the request information to the server, wherein the first player terminal is further configured to execute: After the communication game ends, setting the game state to the impossible state during a predetermined first time period.

9. An information processing system including a server and a plurality of player terminals including a first player terminal, The server is configured to execute: An accumulation step for accumulating prescribed player information for each player in a storage unit; the first player terminal is configured to execute: A request information sending step, for sending request information to the server in response to an input of a request operation from an operation unit of the first player terminal, the request information requesting the server to store invitation information in association with a plurality of other player terminals among the plurality of player terminals, the invitation information inviting players to a communication game that can be played simultaneously by a plurality of players ； and A status storage step, for storing a game status at least based on a game playing situation, the game status including a permission status that permits reporting of reception of the invitation information from the server and an impossible status that does not permit reporting of reception of the invitation information from the server; The server is further configured to execute: A storage step, for, in a case where the request information is received from one of the plurality of player terminals, storing the plurality of player terminals in association with the request information at least based on the specified player information accumulated in the storage unit, and each player terminal associated with the invitation information is set as a receiving terminal capable of receiving the invitation information from the server; The first player terminal is further configured to execute: A judgment step, for judging, based on communication with the server, whether the first player terminal corresponds to one of the receiving terminals stored in response to request information from another player terminal among the plurality of player terminals; A receiving step, for, in a case where the first player terminal corresponds to one of the receiving terminals stored in response to request information from another player terminal among the plurality of player terminals, receiving the invitation information from the server; A storage step, for storing the received invitation information in a memory of the first player terminal; A reporting step, for, in a case where the permission status is stored as the game status, reporting reception of the invitation information when or after receiving the invitation information; and An input receiving step, for receiving an input of a specified participation operation when or after reporting reception of the invitation information; and The server is further configured to execute: A game execution step, for executing a communication game between at least one player terminal that has sent participation information to the server based on an input of the specified participation operation and the player terminal that has sent the request information to the server, wherein the first player terminal is further configured to execute: After the communication game ends, within a predetermined first time period, setting the game status to the impossible status.

Images